3D-MCP

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The tools are generally well-differentiated by resource type (e.g., BlendShapes, Materials) and action (create, delete, update), but there is some overlap in batch operations like batchSetProperty and individual update tools, which could cause confusion. However, descriptions help clarify the scope, preventing severe misselection.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (e.g., createBlendShapes, deleteMaterials, updateVertexs), with clear conventions for CRUD operations. Minor inconsistencies include 'getQuadView' (not pluralized) and 'performGroupOperations' (less specific), but overall naming is predictable and readable.
Tool Count2/5
With 125 tools, the count is excessive for a typical MCP server, making it overwhelming and difficult to navigate. While it covers a broad 3D modeling domain, many tools could be consolidated or omitted without losing functionality, indicating poor scoping.
Completeness5/5
The tool set provides comprehensive coverage for 3D modeling, including full CRUD operations for various resources (e.g., meshes, materials, UV maps), transformation tools, import/export, and utility functions like undo/redo. No obvious gaps exist for the domain, ensuring agents can handle complex workflows.
Average 2.6/5 across 125 of 125 tools scored. Lowest: 1.6/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 Apache 2.0.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description 'Test tool' gives no behavioral information. It does not indicate whether this is a read/write operation, its side effects, permissions needed, or any other behavioral traits, leaving the agent completely uninformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While 'Test tool' is brief, it is under-specified rather than concise. The single phrase fails to convey any meaningful information, making it inefficient and unhelpful despite its short length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is completely inadequate. It provides no context about the tool's function, behavior, or usage, failing to compensate for the missing structured data in a server with many complex sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter information is needed. The description does not add parameter semantics, but this is acceptable given the lack of parameters, aligning with the baseline expectation for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Test tool' is a tautology that merely restates the tool name without specifying any action or resource. It provides no information about what the tool actually does, making it impossible to distinguish from sibling tools or understand its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description offers no context, prerequisites, or exclusions, leaving the agent with no basis for decision-making among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 but provides none. It doesn't indicate whether this is a read-only or mutation operation (though 'perform operations' suggests mutation), what permissions might be required, whether operations are atomic or batched, what happens on failure, or what the tool returns. For a tool that appears to modify group memberships, this lack of behavioral information 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just three words, this is a case of under-specification rather than effective conciseness. The description doesn't earn its place by adding value beyond what's already obvious from the tool name. It's front-loaded only because it's so brief, but the brevity comes at the cost of being unhelpful for tool selection and invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of group operations in a 3D modeling context with no annotations and no output schema, the description is completely inadequate. It doesn't explain what 'object groups' are, what operations can be performed (though the schema shows add/remove/move/nest), what the tool returns, or how it differs from related sibling tools. For a mutation tool with batch operations capability, this minimal description leaves critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters ('operation' and 'items') well-documented in the schema itself. The description adds no additional parameter information beyond what's already in the structured schema. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Perform operations on object groups' is a tautology that essentially restates the tool name 'performGroupOperations'. It lacks specificity about what types of operations are performed (add, remove, move, nest) or what 'object groups' refer to in this 3D modeling context. While it mentions the general domain, it doesn't provide the verb+resource clarity needed to distinguish it from sibling tools like 'createGroups', 'deleteGroups', or 'updateGroups'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or relationships to sibling tools like 'createGroups' or 'updateGroups'. With 75+ sibling tools in this 3D modeling environment, the lack of any usage guidance makes it difficult for an AI agent to determine when this specific group operation tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 but offers none. It doesn't indicate whether this is a destructive operation, what permissions might be required, whether it modifies existing geometry or creates new elements, or what happens to adjacent faces. The description provides zero behavioral context beyond the basic action implied by the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just two words, this represents under-specification rather than effective conciseness. The description doesn't front-load important information and fails to provide any meaningful context. Every word should earn its place, but here the words don't provide sufficient value.
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 complex 3D modeling operation with no annotations and no output schema, the description is completely inadequate. It doesn't explain what extrusion means in this context, what the tool returns, how it affects the scene, or any behavioral characteristics. The agent must rely entirely on the input schema and guesswork about this geometric operation.
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%, so the schema already documents the single parameter 'items' and its nested properties comprehensively. The description adds no parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Extrude faces' is a tautology that merely restates the tool name without adding any meaningful context. It doesn't specify what extrusion means in this context, what resource it operates on (e.g., 3D mesh faces), or how it differs from sibling tools like 'createFaces' or 'updateFaces'. While the name suggests a 3D modeling operation, the description provides no additional clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. There's no mention of prerequisites, context, or comparison to sibling tools like 'createFaces', 'updateFaces', or other mesh manipulation tools. The agent must infer usage entirely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 but offers none. It doesn't indicate whether this is a read-only operation, whether it might be destructive, what authentication might be required, rate limits, pagination behavior (despite having offset/limit parameters), or what format the results will be in. The single phrase provides no behavioral context whatsoever.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with only three words, this description suffers from severe under-specification rather than effective conciseness. The single phrase 'List all UVMaps' fails to provide necessary context and guidance. True conciseness balances brevity with completeness - this description is brief but inadequate, not efficiently 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?
For a tool with 4 parameters, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what UVMaps are in this context (3D modeling/texture mapping), doesn't describe the return format, doesn't provide usage context, and offers no behavioral transparency. Given the complexity implied by the sibling tools (3D modeling operations) and lack of structured documentation, this description leaves critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema itself. The description adds no parameter information beyond what the schema provides - it doesn't explain what UVMaps are, what filters might be applicable, or how parentId relates to the resource hierarchy. Given the high schema coverage, the baseline score of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all UVMaps' is essentially a tautology that restates the tool name 'listUVMaps' without adding meaningful context. While it does specify the resource (UVMaps), it lacks a specific verb beyond 'List' and doesn't distinguish this tool from its sibling 'getUVMaps' which appears to serve a similar purpose. The description fails to clarify what differentiates listing from getting in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. There's no mention of when to choose listUVMaps over getUVMaps (its obvious sibling), no context about prerequisites or typical use cases, and no exclusion criteria. The agent receives zero usage direction beyond the tool name itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 but provides none. It doesn't indicate whether this is a read or write operation (though 'create' implies mutation), what permissions might be required, whether it's destructive to existing data, what happens on failure, or what the return value might be. For a creation tool with complex parameters, this lack of behavioral context is severely 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 extremely concise at just two words, which could be appropriate if it were more informative. However, this brevity comes at the cost of being under-specified rather than efficiently informative. It's front-loaded with the core action but lacks necessary context. While not verbose or poorly structured, it's too minimal to be truly effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations, no output schema, and complex nested parameters (though well-documented in schema), the description is completely inadequate. It doesn't explain what Joints are, what creation entails, what happens after creation, error conditions, or any behavioral aspects. The agent must rely entirely on the schema and tool name inference, which is insufficient for safe and effective tool invocation.
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 single 'items' parameter and all its nested properties. The description adds no parameter information beyond what's already in the schema - it doesn't explain what constitutes a valid Joint, provide examples, or clarify relationships between parameters. With complete schema coverage, the baseline score of 3 is appropriate as the description doesn't add value but doesn't need to compensate for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create multiple Joints' is a tautology that merely restates the tool name 'createJoints' with the addition of 'multiple'. It doesn't specify what Joints are in this context (3D modeling joints, mechanical joints, etc.) or what 'create' actually does (adds to scene, generates in database, etc.). While it distinguishes from deletion tools by being a creation tool, it doesn't differentiate from other creation tools like 'createIKChains' or 'createConstraints' beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. It doesn't mention when to use createJoints versus createIKChains (which might be related), when to use batch creation versus single creation (if such a tool exists), or any prerequisites like needing a scene context. The agent must infer usage purely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 but offers none. 'Create multiple Drivers' doesn't indicate whether this is a read-only or destructive operation, what permissions might be required, whether it's idempotent, what happens on failure, or what the expected output looks like. For a creation tool with zero annotation coverage, this is a critical gap that leaves the agent guessing about important behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just two words. While this brevity comes at the cost of completeness, every word earns its place - 'Create' specifies the action and 'multiple Drivers' indicates the plural nature of the operation. There's no wasted language or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that creates complex entities with a detailed input schema (nested objects describing Drivers with expressions, variables, targets, etc.) and no output schema, the description is completely inadequate. It doesn't explain what Drivers are, their purpose in the system, what happens after creation, or any behavioral aspects. With no annotations and a complex parameter structure, the description fails to provide the necessary context for effective tool 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 mentions 'multiple Drivers' which hints at the 'items' parameter being an array, but provides no additional semantic context beyond what's already in the schema. Since schema description coverage is 100% (all parameters are well-documented in the schema), the baseline score of 3 is appropriate. The description doesn't add meaningful information about parameter usage, constraints, or relationships that aren't already covered by the comprehensive schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create multiple Drivers' is a tautology that essentially restates the tool name. It doesn't specify what a 'Driver' is in this context or what the creation entails. While it indicates the plural nature ('multiple'), it lacks the specificity needed to distinguish this tool from other creation tools like createChannels, createConstraints, or createMaterials in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. There are many sibling tools for creating different types of entities (createChannels, createConstraints, createMaterials, etc.), but the description doesn't explain what makes Drivers unique or when they should be created instead of other entities. No prerequisites, context, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 but offers none. It doesn't indicate whether this is a destructive operation, what permissions are required, how errors are handled, or what happens on success (e.g., returns edge IDs). The single word 'Create' implies mutation but lacks essential context about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just two words, with zero wasted language. It's front-loaded with the core action ('Create') and object ('Edges'), though this brevity comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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 completely inadequate. It doesn't explain what Edges are, their role in 3D meshes, expected outcomes, error conditions, or relationships to other tools. The agent lacks sufficient context to use this tool effectively.
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 single 'items' parameter and its nested properties. The description adds no parameter information beyond what's in the schema, maintaining the baseline score of 3 where structured data does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create multiple Edges' is a tautology that restates the tool name with minimal elaboration. While it specifies 'multiple' (implying batch creation), it doesn't explain what 'Edges' are in this 3D modeling context or distinguish this tool from sibling tools like 'createFaces' or 'createVertexs' that create other mesh components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 existing vertices or meshes), appropriate contexts, or relationships to sibling tools like 'createFaces' or 'updateEdges'. The agent receives no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 but provides none. It doesn't indicate whether this is a destructive operation, whether it requires specific permissions or context, what happens to existing vertex data, or what the expected outcome looks like. For a tool that modifies geometry vertices, this lack of behavioral information is particularly problematic.
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 maximally concise - just three words. While this represents under-specification rather than ideal conciseness, according to the scoring framework, 'Process' received a 2 for being under-specified, but this description is even more minimal. However, every word earns its place, and there's zero redundancy or wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool (transforming vertices implies modification) with no annotations, no output schema, and complex nested parameter structure, the description is completely inadequate. It doesn't explain what 'transform' means operationally, what the tool returns, or provide any context about the transformation behavior. For a geometry manipulation tool, this level of incompleteness is severe.
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%, so the schema already documents the single 'items' parameter and its nested structure thoroughly. The description adds no parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Transform multiple vertices' is a tautology that essentially restates the tool name 'transformVertices'. It doesn't specify what kind of transformation occurs (position, normal, offset) or what resource is being transformed. While the name suggests 3D geometry operations, the description adds no meaningful clarification beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. With sibling tools like 'batchTransform', 'transformUVs', 'updateVertexs', and various vertex manipulation tools in the list, there's no indication of when this specific vertex transformation tool is appropriate versus other transformation or update operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but fails to disclose behavioral traits. It doesn't indicate whether this is a destructive operation (modifies meshes), requires specific permissions, has side effects (e.g., altering mesh topology), or what happens on failure. The description is too minimal to guide safe or effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that directly states the tool's action. There's no wasted verbiage or unnecessary elaboration, making it front-loaded and efficient. Every word earns its place, though this brevity contributes to other deficiencies.
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 3D modeling operation with no annotations and no output schema, the description is incomplete. It doesn't explain what a 'bridge' is, the expected outcome (e.g., new faces/edges), error conditions, or how it fits within the sibling toolset. For a tool that likely modifies mesh geometry, this minimal description is inadequate.
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%, providing clear documentation for all parameters (items array with faceLoopA, faceLoopB, meshId, smooth, twist). The description adds no parameter semantics beyond the schema, but since the schema is comprehensive, the baseline score of 3 is appropriate as the description doesn't need to compensate for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create bridges between face loops' states a basic action but lacks specificity. It doesn't explain what a 'bridge' operation entails in 3D modeling context (e.g., connecting loops with new geometry), nor does it differentiate from sibling tools like 'createEdges' or 'createFaces' that might handle similar mesh operations. The purpose is vague beyond the literal interpretation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., requiring existing face loops), exclusions (e.g., not for non-loop edges), or suggest related tools like 'createEdges' or 'createFaces' for different mesh creation tasks. This leaves the agent with no contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 'Create multiple Constraints', implying a write/mutation operation, but fails to describe any behavioral traits such as permissions needed, whether creation is reversible, error conditions, or side effects. This leaves the agent with no insight into how the tool behaves beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two words, 'Create multiple Constraints'. It is front-loaded and wastes no words, though this brevity contributes to its inadequacy in other dimensions. Every word earns its place by directly stating the action and resource.
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 creating constraints in 3D modeling (inferred from sibling tools), the description is incomplete. No annotations or output schema exist to supplement it, and the description lacks context on what constraints are, their purpose, or behavioral details. For a mutation tool with no structured support, this minimal description fails to provide adequate completeness for an agent to use it effectively.
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%, meaning the input schema fully documents the single parameter 'items' and its nested properties. The description adds no additional parameter semantics beyond what's in the schema. According to the rules, with high schema coverage (>80%), the baseline score is 3 when no param info is added in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create multiple Constraints' restates the tool name with minimal elaboration. It specifies the verb ('Create') and resource ('Constraints'), but lacks detail on what Constraints are or their purpose in the 3D modeling context, making it vague. Compared to siblings like 'createJoints' or 'createMaterials', it doesn't differentiate beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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., existing objects to constrain), exclusions, or related tools like 'updateConstraints' or 'deleteConstraints'. The agent must infer usage from the tool name alone, which is insufficient for effective selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 only states 'Create multiple Materials' without explaining what happens upon creation (e.g., are materials added to a scene, saved to a file, require specific permissions, have side effects like resource allocation, or return identifiers). This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two words, front-loading the key action and resource. There is no wasted language, making it efficient for quick scanning, though this conciseness comes at the cost of detail.
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 creating materials with multiple nested properties (as shown in the schema), no annotations, and no output schema, the description is incomplete. It doesn't explain the purpose, usage context, behavioral aspects, or what to expect after creation, leaving significant gaps for an AI agent to understand and use the tool effectively.
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 single parameter 'items' and its nested properties. The description adds no additional meaning beyond implying multiple items can be created, which is already clear from the schema. Baseline 3 is appropriate when the schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create multiple Materials' states the action and resource but is vague about what 'Materials' are in this context (3D modeling materials, educational materials, etc.). It distinguishes from siblings like 'createMeshs' or 'createUVMaps' by specifying 'Materials', but lacks specificity about the domain or what creation entails beyond the basic verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. Sibling tools include 'createMeshs', 'createUVMaps', and 'updateMaterials', but the description doesn't indicate when creation is appropriate over updates or how it relates to other creation tools. There's no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. 'Create' implies a write/mutation operation, but the description doesn't disclose any behavioral traits: no information about permissions needed, whether this is destructive to existing data, rate limits, error conditions, or what happens on success. This leaves the agent completely in the dark about the tool's behavior 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 maximally concise at three words with zero wasted language. It's front-loaded with the core action and resource. While under-specified, it's not verbose or poorly structured - every word directly contributes to stating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation/mutation tool with no annotations and no output schema, the description is severely incomplete. It doesn't explain what SubdivisionSurfaces are, what 'create' actually does operationally, what happens to the created objects, or what the tool returns. The agent would need to guess about the tool's behavior and outcomes based solely on the name and parameter schema.
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 'items' parameter and all nested properties thoroughly. The description adds no parameter information beyond what's in the schema - it doesn't explain what 'SubdivisionSurfaces' are, why you'd create them, or provide any context for the parameter values. Baseline 3 is appropriate when the schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create multiple SubdivisionSurfaces' is a tautology that essentially restates the tool name. While it specifies 'multiple' (plural), it doesn't explain what SubdivisionSurfaces are or what creation entails. Compared to sibling tools like 'createMeshs' or 'createBlendShapes', it doesn't differentiate beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. There's no mention of prerequisites (e.g., needing a base mesh), when not to use it, or how it relates to sibling tools like 'createMeshs' or 'updateSubdivisionSurfaces'. The agent receives zero contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. 'Duplicate an entity' only states the basic action without any information about side effects, permissions required, whether the operation is reversible, rate limits, or what the output looks like. For a mutation tool that creates new entities, this lack of behavioral context is a critical gap that leaves the agent guessing about important operational characteristics.
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 maximally concise with just three words: 'Duplicate an entity.' While this represents under-specification rather than ideal conciseness, according to the scoring framework, extremely brief descriptions that don't waste words receive high conciseness scores. Every word serves a purpose, even if that purpose is insufficiently informative.
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 duplication operation (creating new entities with configurable options for children and dependencies), no annotations, and no output schema, the description is severely incomplete. It doesn't explain what 'entity' means in this context, what happens during duplication, what the result looks like, or any error conditions. The agent would need to guess about fundamental aspects of this tool's behavior and output.
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%, meaning all four parameters (id, newName, duplicateChildren, duplicateDependencies) are documented in the input schema with clear descriptions. The tool description adds no additional parameter information beyond what the schema provides. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Duplicate an entity' is a tautology that essentially restates the tool name 'duplicate' without adding meaningful specificity. While it indicates the verb (duplicate) and resource (entity), it doesn't clarify what type of entity (e.g., mesh, material, group) or distinguish this tool from potential alternatives among the many sibling tools. This minimal description fails to provide the context needed for an AI agent to understand what exactly is being duplicated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. With numerous sibling tools like 'createMeshs', 'copy', 'batchTransform', and others that might create or replicate entities, there's no indication of when duplication is preferred over creation or other operations. The agent receives no context about prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 only states the action ('Get metadata') without describing permissions, side effects, rate limits, or return format. This is inadequate for a tool that likely interacts with a 3D modeling system, as seen in sibling tools.
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 no wasted words. It is front-loaded and appropriately sized for the tool's apparent simplicity, though this conciseness comes at the cost of detail.
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 lack of annotations and output schema, and the description's minimal content, this is incomplete. It does not address behavioral aspects, usage context, or return values, which are critical for a tool in a complex 3D modeling environment with many sibling tools.
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 parameter descriptions in the input schema. The description adds no additional meaning beyond what the schema provides, such as examples or constraints. Baseline score of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get metadata from an entity' restates the tool name 'getMetadata' without adding specificity. It does not clarify what type of entity (e.g., 3D model component, scene object) or what metadata format is involved, nor does it distinguish from sibling tools like 'getProperty' or 'query' that might retrieve similar information. This is a tautology with minimal added value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, context, or exclusions, and it fails to differentiate from sibling tools such as 'getProperty' or 'setMetadata'. This leaves the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the action without mentioning pagination behavior, rate limits, permissions, or output format, failing to add meaningful context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single three-word phrase, front-loaded and free of unnecessary words. It efficiently communicates the core action without waste, though this brevity contributes to gaps in other dimensions.
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 no annotations and no output schema, the description is incomplete for a tool with 4 parameters and complex filtering capabilities. It lacks details on behavior, output, and usage context, making it inadequate for effective tool invocation.
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 documented in the schema. The description adds no semantic details beyond implying a list operation, aligning with the baseline score when the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all Clips' restates the tool name with minimal elaboration, making it tautological. It specifies the verb 'List' and resource 'Clips' but lacks detail on scope or differentiation from sibling tools like 'getClips', leaving the purpose vague beyond basic listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 such as 'getClips' or other list tools. The description offers no context, prerequisites, or exclusions, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. 'List all Materials' fails to describe any behavioral aspects such as pagination behavior (implied by limit/offset parameters), whether it's read-only or has side effects, performance considerations, or error handling. It provides no insight into how the tool operates 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 extremely concise with just three words, making it front-loaded and free of unnecessary information. Every word contributes directly to stating the tool's action, though it lacks depth. This efficiency in length is optimal for minimal descriptions.
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 listing tool with four parameters, no annotations, and no output schema, the description is incomplete. It fails to explain what 'Materials' are, how results are structured, or behavioral traits like pagination. While the schema covers parameters, the overall context for effective tool use is insufficient.
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, clearly documenting all four parameters (filters, limit, offset, parentId). The description adds no parameter semantics beyond what the schema provides, but since schema coverage is high, the baseline score of 3 is appropriate as the schema adequately handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all Materials' is a tautology that merely restates the tool name without adding meaningful context. While it indicates a listing operation on Materials, it lacks specificity about what 'Materials' are in this domain or how this differs from similar tools like 'getMaterials' or 'listBlendShapes' among the siblings. It provides minimal value beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. With many sibling tools like 'getMaterials', 'listBlendShapes', and 'query', there is no indication of context, prerequisites, or distinctions. This leaves the agent without direction on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Create multiple Faces' implies a write/mutation operation, but it doesn't specify whether this is destructive to existing data, requires specific permissions, has side effects, or how failures are handled. For a creation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 extremely concise at just three words, with zero wasted language. However, this brevity comes at the cost of being under-specified for a complex creation tool. While structurally efficient, it lacks the necessary explanatory content that would make it truly helpful.
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 no annotations, no output schema, and complex nested parameters (faces with normals, vertex IDs, materials), the description is incomplete. It doesn't explain what Faces are, how they relate to other entities (meshes, vertices), what happens on creation, or what the tool returns. The agent must rely entirely on the input schema for understanding.
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 single 'items' parameter and its nested properties. The description adds no parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create multiple Faces' states the action (create) and resource (Faces), but it's vague about what Faces are in this 3D modeling context and doesn't differentiate from sibling tools like createEdges, createVertexs, or createMeshs. It restates the tool name without providing specific context about what Faces represent in the system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 createMeshs, createEdges, or updateFaces. There's no mention of prerequisites (e.g., needing existing vertices or meshes), typical workflows, or exclusion criteria. The agent must infer usage from the parameter schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Import' implies a write operation that adds data to the system, but the description doesn't specify whether this overwrites existing geometry, requires specific permissions, has side effects (e.g., creating materials), or handles errors. For a mutation tool with zero annotation coverage, this minimal description leaves critical behavioral traits undocumented.
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 extremely concise with just three words, making it front-loaded and efficient. However, this conciseness comes at the cost of under-specification—it lacks necessary details about purpose, usage, and behavior. While not verbose, it fails to earn its place by providing sufficient value, so it doesn't merit a perfect score.
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 (importing geometry with multiple formats and options), the absence of annotations, and no output schema, the description is incomplete. It doesn't explain what happens after import (e.g., geometry added to scene, return values), behavioral constraints, or error handling. For a mutation tool in a 3D modeling context with rich sibling tools, this minimal description is inadequate.
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 single parameter 'items' and its nested properties (format, data, options). The description adds no parameter information beyond what's in the schema. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Import geometry data sources' is a tautology that essentially restates the tool name 'importGeometry'. It lacks a specific verb-resource combination that clarifies what the tool actually does (e.g., 'imports geometry files into the 3D scene' or 'loads external geometry data'). While it distinguishes from siblings like 'exportGeometry', it doesn't provide meaningful differentiation beyond the obvious name contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 geometry files), exclusions (e.g., not for modifying existing geometry), or contextual cues (e.g., use for initial scene setup). With many sibling tools for geometry manipulation (like 'combineMeshes', 'extrudeFaces'), the absence of usage guidelines is a significant gap.
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. 'List all Joints' implies a read operation but doesn't disclose behavioral traits like pagination behavior, rate limits, authentication requirements, or what 'all' means in practice (e.g., scope limitations). It mentions no side effects or safety considerations.
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 extremely concise at just three words, with no wasted text. However, this brevity comes at the cost of being under-specified rather than efficiently informative. It's front-loaded but lacks substance.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what a Joint is, what the output format looks like, or any behavioral context. For a tool with 4 parameters and complex sibling relationships, this minimal description leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description adds no parameter semantics beyond what's in the schema. Baseline 3 is appropriate since the schema does the heavy lifting, but the description provides no additional context about parameter usage or interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all Joints' restates the tool name 'listJoints' almost verbatim, making it a tautology. It specifies the verb 'List' and resource 'Joints', but doesn't clarify what Joints are in this context or how this differs from sibling tools like 'getJoints' or 'createJoints'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. There's no mention of prerequisites, when to choose listJoints over getJoints, or any contextual constraints. The description offers zero usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Create' implies a write operation, but it doesn't specify if this is destructive (e.g., overwrites existing shapes), requires specific permissions, has side effects, or how errors are handled. The description lacks any 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 with zero waste. It's appropriately sized and front-loaded, though it lacks detail, this is a matter of completeness, not 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 complexity (creating multiple 3D modeling objects with nested parameters), no annotations, and no output schema, the description is inadequate. It doesn't explain what BlendShapes are, the expected return values, error conditions, or usage context, leaving significant gaps 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 schema fully documents the single parameter 'items' and its nested properties. The description adds no parameter semantics beyond what's in the schema, but the baseline is 3 since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create multiple BlendShapes' states the basic action and resource but is tautological with the tool name 'createBlendShapes'. It doesn't differentiate from siblings like 'updateBlendShapes' or 'deleteBlendShapes' beyond the verb, nor does it specify what BlendShapes are in this context (e.g., 3D modeling deformations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 'updateBlendShapes' or 'getBlendShapes'. It doesn't mention prerequisites (e.g., needing an existing mesh), exclusions, or typical use cases, leaving the agent to infer usage from the 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?
No annotations are provided, so the description carries full burden. It states 'create' implying a write operation but does not disclose behavioral traits like whether it requires specific permissions, if it's idempotent, what happens on failure, or if it modifies existing state. The description adds no context beyond the basic action, leaving critical behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, front-loading the action and resource. There is no wasted language or unnecessary elaboration, making it efficient for quick understanding, though this conciseness comes at the cost of detail.
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 creating 3D curves with multiple nested parameters, no annotations, and no output schema, the description is incomplete. It does not explain the context (e.g., 3D modeling environment), expected outcomes, error handling, or how it fits with sibling tools. For a tool with rich input schema but no other structured data, more descriptive 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?
Schema description coverage is 100%, so the schema fully documents the single parameter 'items' and its nested properties. The description adds no meaning beyond the schema, as it does not explain parameter usage, constraints, or examples. Baseline 3 is appropriate since the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create multiple Curves' restates the tool name with minimal elaboration, making it tautological. It specifies the verb 'create' and resource 'Curves' but lacks detail about what Curves are in this context or how they differ from other creation tools like createMeshs or createJoints. This provides only basic purpose without sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context (e.g., 3D modeling), or compare with sibling tools like createMeshs or updateCurves. Without any usage context, the agent must infer when this tool is 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 full burden for behavioral disclosure. It states 'Create multiple Keyframes', implying a write/mutation operation, but doesn't clarify permissions, side effects, error handling, or response format. For a tool that likely modifies data, this lack of detail is a significant gap, leaving the agent uncertain about behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single three-word phrase. It is front-loaded and wastes no words, though this brevity contributes to underspecification in other dimensions. Every word directly states the core action without fluff.
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 (creating multiple structured keyframes with nested objects), no annotations, and no output schema, the description is incomplete. It fails to explain what keyframes are, their role in the system, or what the tool returns. For a mutation tool with rich input schema, more context is needed to guide 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?
Schema description coverage is 100%, with detailed parameter documentation in the input schema. The description adds no parameter-specific information beyond implying multiple items via 'multiple Keyframes', which is already covered by the 'items' array in the schema. Baseline score of 3 is appropriate as the schema handles parameter semantics adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create multiple Keyframes' is a tautology that restates the tool name with minimal elaboration. It specifies the verb 'Create' and resource 'Keyframes' but lacks specificity about what keyframes are or their domain (e.g., animation, graphics). Compared to siblings like 'createChannels' or 'createJoints', it doesn't differentiate the purpose beyond the basic action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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., existing channels), exclusions, or related tools like 'updateKeyframes' or 'deleteKeyframes' from the sibling list. The description offers no context for usage decisions.
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 the full burden of behavioral disclosure. It states 'create' implying a write operation but does not cover permissions, side effects, error handling, or response format. This is inadequate for a tool that likely modifies state, leaving critical behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, 'Create multiple Meshs', which is front-loaded and wastes no words. It efficiently conveys the core action 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 no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits, usage context, and expected outcomes, failing to compensate for the absence of structured metadata, which is critical for effective tool invocation.
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 single parameter 'items' and its nested properties. The description adds no additional meaning beyond implying batch creation, aligning with the baseline score when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create multiple Meshs' restates the tool name with minimal elaboration, making it tautological. It specifies the verb 'create' and resource 'Meshs' but lacks detail about what a 'Mesh' is or the scope of creation, failing to distinguish it from sibling tools like 'createMaterials' or 'createVertexs' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 does not mention prerequisites, context for batch creation, or comparisons to related tools like 'createVertexs' or 'combineMeshes', leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Create multiple UVMaps' implies a write operation but doesn't specify permissions, side effects (e.g., overwriting existing UVMaps), error handling, or output format. It lacks critical details like whether creation is atomic or batch-oriented, making it insufficient 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 with no wasted words. It's front-loaded and appropriately sized for the tool's complexity, though it could benefit from more detail given the lack of annotations and output schema.
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 UVMaps are, their role in 3D modeling, expected outcomes, or error conditions. Given the rich input schema and sibling tools like 'getUVMaps' and 'updateUVMaps', more context is needed to guide 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?
Schema description coverage is 100%, so the schema fully documents the 'items' parameter and its nested structure. The description adds no additional parameter semantics beyond implying multiple items can be created, which is already clear from the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create multiple UVMaps' restates the tool name with minimal elaboration, making it tautological. It specifies the verb ('Create') and resource ('UVMaps') but lacks detail on what UVMaps are or their purpose, and doesn't differentiate from sibling tools like 'createMeshs' or 'updateUVMaps' beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 existing meshes), exclusions, or comparisons to related tools like 'createMeshs', 'getUVMaps', or 'updateUVMaps', leaving usage context unclear.
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. 'Create multiple Vertexs' implies a write operation but doesn't disclose behavioral traits like whether this requires specific permissions, if it's idempotent, what happens on failure, or how it interacts with existing geometry. The description is minimal and lacks crucial context 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 extremely concise with just three words. It's front-loaded and wastes no words, though this conciseness comes at the cost of completeness. Every word directly relates to the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what a 'Vertex' is, how creation affects the system, what the return value might be, or error conditions. The high schema coverage helps with parameters, but overall context is severely lacking.
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 single parameter 'items' and its nested properties. The description adds no additional parameter semantics beyond what the schema provides, which meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create multiple Vertexs' restates the tool name with minor variation, making it tautological. It specifies the verb 'Create' and resource 'Vertexs' but lacks specificity about what a 'Vertex' is in this context or how this differs from similar tools like 'createMeshs' or 'createEdges'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. There are many sibling creation tools (e.g., createMeshs, createEdges, createFaces), but the description offers no context about when vertex creation is appropriate, prerequisites, 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 full burden but only states the action 'Delete multiple Meshs'. It fails to disclose critical behavioral traits such as whether deletion is permanent, requires permissions, has side effects, or returns confirmation, leaving significant gaps 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, efficient sentence with zero waste, front-loading the core action. It is appropriately sized for the tool's simple function, though it lacks depth, this reflects conciseness rather than under-specification.
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, no annotations, and no output schema, the description is incomplete. It should address behavioral aspects like irreversibility or error handling, but only states the basic action, leaving the agent under-informed for safe and 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?
Schema description coverage is 100%, with the parameter 'ids' clearly documented as 'Mesh identifiers to delete'. The description adds no additional meaning beyond the schema, but since coverage is high, the baseline score of 3 is appropriate as the schema adequately defines the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete multiple Meshs' restates the tool name 'deleteMeshs' with minimal elaboration, making it tautological. It specifies the verb 'Delete' and resource 'Meshs' but lacks detail on scope or differentiation from similar tools like 'deleteMaterials' or 'deleteVertexs', offering only basic purpose without specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or sibling tools like 'deleteMaterials' or 'deleteVertexs', leaving the agent without context for selection among deletion operations.
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. 'List all Vertexs' suggests a read-only operation that returns data, but it doesn't specify whether this is a safe query (no side effects), what format the results take, whether there are rate limits, or if authentication is required. For a tool with 4 parameters and no annotation coverage, this minimal description leaves critical behavioral aspects undefined, though it doesn't contradict any 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 extremely concise at just three words, with zero wasted language. It's front-loaded with the core purpose and contains no unnecessary elaboration. While under-specified in content, it achieves perfect efficiency in form—every word directly contributes to stating the tool's basic function without redundancy or structural issues.
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 (4 parameters, no annotations, no output schema, and many sibling tools), the description is incomplete. It doesn't explain what 'Vertexs' are, how results are returned, or how this differs from similar tools. While the schema covers parameters, the description fails to provide necessary context about the tool's role in the broader system, leaving significant gaps for an AI agent to understand when and how to use it effectively.
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, with clear documentation for all 4 parameters (filters, limit, offset, parentId). The tool description adds no parameter information beyond what's already in the schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here since the schema fully documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all Vertexs' is a tautology that essentially restates the tool name 'listVertexs' with minimal elaboration. While it indicates a listing operation on 'Vertexs', it lacks specificity about what 'Vertexs' are in this context (likely 3D modeling vertices) and doesn't distinguish this tool from similar sibling tools like 'getVertexs' or 'transformVertices'. The description provides the basic verb+resource but fails to add meaningful differentiation or context.
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. With sibling tools like 'getVertexs' (which might retrieve specific vertices) and 'transformVertices' (which modifies vertices), there's clear potential for confusion, but the description offers no comparison or context about appropriate use cases. The agent receives no help in determining whether this is for browsing, filtering, or general inspection versus more targeted operations.
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. 'Delete multiple Vertexs' implies a destructive operation but doesn't disclose critical behavioral traits: whether deletion is permanent/reversible, what happens to connected geometry, permission requirements, or error handling for invalid IDs. This is inadequate for a destructive 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, which is efficient for such a simple operation. However, it's arguably too brief given the destructive nature and lack of annotations, potentially sacrificing clarity for brevity.
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 deletion tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'Vertexs' are, what the deletion affects, whether there are side effects, or what happens on success/failure. Given the complexity and risk of deletion operations, 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?
Schema description coverage is 100% with the parameter 'ids' documented as 'Vertex identifiers to delete'. The description adds no additional parameter semantics beyond what the schema provides, but with complete schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete multiple Vertexs' clearly states the action (delete) and resource (Vertexs), but it's vague about scope and doesn't differentiate from sibling tools like 'deleteVertexs' vs 'deleteEdges' or 'deleteFaces'. It lacks specificity about what 'Vertexs' are in this context.
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. With many sibling deletion tools (deleteBlendShapes, deleteEdges, deleteFaces, etc.), the description offers no context about when vertex deletion is appropriate versus other deletion operations.
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 'List all BlendShapes' but doesn't mention whether this is a read-only operation, if it requires specific permissions, how results are returned (e.g., paginated, sorted), or any side effects. For a tool with 4 parameters and no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, 'List all BlendShapes', which is front-loaded and wastes no words. It could be more structured by including context or usage hints, but it's appropriately concise for its minimal content.
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 (4 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what BlendShapes are, how results are formatted, or behavioral aspects like pagination or filtering. For a tool with multiple parameters and no output schema, more context is needed to be fully helpful.
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 all 4 parameters (filters, limit, offset, parentId). The description adds no parameter-specific information beyond what the schema provides, such as example filters or usage of parentId. Given the high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all BlendShapes' clearly states the verb ('List') and resource ('BlendShapes'), making the basic purpose understandable. However, it doesn't differentiate from sibling tools like 'getBlendShapes' or specify what 'all' means in context (e.g., all in a scene, project, or selection). This vagueness prevents a higher score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'getBlendShapes' or other list tools (e.g., 'listMaterials'). The description implies a listing operation but doesn't specify prerequisites, context, or exclusions, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a read-only operation ('List') but doesn't disclose pagination behavior (hinted by 'limit' and 'offset' in schema), filtering capabilities, or potential side effects like performance impacts. More context is needed for a mutation-heavy server environment.
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 'List all Layers' is extremely concise and front-loaded, with no wasted words. It efficiently communicates the core action, though it could benefit from slightly more detail to improve clarity without sacrificing brevity.
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 3D modeling/server context with many sibling tools, no annotations, and no output schema, the description is inadequate. It doesn't explain return values, error conditions, or how it fits into workflows (e.g., vs. 'getLayers'), leaving significant gaps for an AI agent to infer usage.
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%, so parameters like 'filters', 'limit', 'offset', and 'parentId' are documented in the schema. The description adds no additional meaning beyond implying listing, which aligns with the schema but doesn't compensate for or enhance parameter understanding beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all Layers' clearly states the verb ('List') and resource ('Layers'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'getLayers' (which might retrieve specific layers) or other list tools (e.g., 'listMaterials'), leaving ambiguity about scope or uniqueness.
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 sibling tools like 'getLayers' (which might fetch specific layers) or 'listMaterials' (for other resources), nor does it specify prerequisites, contexts, or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'List all Meshs' implies a read-only operation but doesn't specify whether it returns complete or partial data, how results are ordered, or any limitations. It mentions 'all' but the parameters suggest filtering/pagination capabilities, creating some ambiguity about what 'all' means.
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 extremely concise at just three words, with no wasted text. However, this brevity comes at the cost of completeness - it's arguably too minimal for a tool with 4 parameters and many sibling alternatives. The structure is front-loaded but under-specified.
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 list operation with 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'Meshs' are in this context, how results are returned, or how parameters interact. With many similar sibling tools, more context is needed to distinguish this tool's specific role and 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 100%, so the schema fully documents all 4 parameters. The description adds no parameter-specific information beyond the generic 'List all Meshs' statement. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't enhance understanding of how parameters affect the listing operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all Meshs' clearly states the action (list) and resource (Meshs), providing basic purpose. However, it doesn't differentiate from similar sibling tools like 'getMeshs' or other list tools, and the plural 'Meshs' (likely a typo for 'Meshes') creates ambiguity about the resource being listed.
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. With many sibling tools including 'getMeshs' and other list operations, there's no indication of whether this is for filtered listing, paginated results, or different use cases. The agent must infer usage from parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Select one or more objects' implies a non-destructive operation that changes application state, but it doesn't disclose critical behavioral traits: whether selection persists across operations, if it requires specific object types, what happens with invalid IDs, or if it triggers UI updates. For a state-changing tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - just one sentence with four words. While efficient, it may be under-specified rather than appropriately concise. Every word earns its place, but more context might be needed for this operation in a complex 3D modeling environment.
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 state-changing operation in a complex 3D modeling system with no annotations and no output schema, the description is incomplete. It doesn't explain what 'selection' means in this context, how it affects other operations, what gets returned (if anything), or error conditions. The tool interacts with many sibling operations but provides no context about those relationships.
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 three parameters (ids, mode, domain) with descriptions and enum values for mode. The description adds no parameter information beyond what's in the schema. According to guidelines, when schema coverage is high (>80%), the baseline is 3 even with no param info in description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Select one or more objects' states a clear verb ('select') and resource ('objects'), but it's vague about what 'select' means in this 3D modeling context. It doesn't specify whether this is for UI highlighting, data retrieval, or setting active objects for operations. Compared to sibling tools like 'getSelection' (which retrieves current selection) and 'clearSelection' (which clears selection), it lacks 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 when selection is needed (e.g., before applying transformations or edits), how it relates to 'getSelection' (which retrieves rather than sets selection), or what happens with the selected objects afterward. There's no context about prerequisites or typical workflows.
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. 'Set metadata' implies a write operation, but it fails to describe key behaviors: whether it requires specific permissions, if it overwrites or merges metadata (though the schema hints at merging via the 'merge' parameter), error conditions, or what the response looks like. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it front-loaded and easy to parse. However, it lacks structural elements like bullet points or examples that could enhance clarity without sacrificing brevity.
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 mutation tool with no annotations and no output schema, the description is incomplete. It does not explain the outcome, error handling, or interaction with siblings (e.g., 'getMetadata'), leaving significant gaps for an AI agent to understand how to use it effectively in 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%, with clear descriptions for 'id' (entity identifier), 'merge' (whether to merge with existing metadata), and 'metadata' (metadata to set). The description adds no additional meaning beyond the schema, such as format examples or constraints, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set metadata on an entity' clearly states the action (set) and target (metadata on an entity), avoiding tautology. However, it lacks specificity about what type of entity (e.g., 3D object, mesh, material) or what metadata entails, and does not distinguish it from sibling tools like 'getMetadata' or 'update*' tools, making it somewhat vague.
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 does not mention prerequisites (e.g., entity must exist), exclusions, or compare it to siblings like 'getMetadata' for reading metadata or 'update*' tools for other modifications, leaving usage unclear.
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 provides minimal behavioral insight. It implies a write operation ('Update') but doesn't disclose critical traits like permission requirements, whether updates are destructive or reversible, error handling for invalid IDs, or if it's atomic (all-or-nothing). The description adds no context beyond the basic action, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it appropriately concise. However, it's front-loaded only in the sense that it's brief, but it lacks structural elements like clarifying the domain or usage, which could improve clarity without sacrificing brevity.
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 (batch update of Constraints with many nested parameters), no annotations, and no output schema, the description is incomplete. It fails to explain what Constraints are, the impact of updates, return values, or error conditions. For a mutation tool in a 3D modeling context, this leaves the agent with insufficient information to use it effectively.
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 'items' parameter and its nested properties. The description adds no meaning beyond what the schema provides—it doesn't explain the structure of 'items', clarify that 'ids' are required, or give examples. With high schema coverage, the baseline is 3, and the description doesn't compensate with additional insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Update') and resource ('multiple Constraints'), which provides a basic purpose. However, it's vague about what Constraints are (3D modeling constraints like point, aim, etc.) and doesn't differentiate from sibling tools like 'updateBlendShapes' or 'updateMaterials' beyond the resource name. It lacks specificity about the operation's scope or domain context.
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., existing Constraints), compare to single-update tools if they exist, or specify scenarios like batch operations. The description only restates the tool's function without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'update' but doesn't disclose behavioral traits like whether it's idempotent, requires specific permissions, overwrites existing data, or handles errors. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it easy to parse. However, it could be more front-loaded with key details, but overall, it's appropriately sized for 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 (batch mutation of UVMaps with nested parameters), no annotations, and no output schema, the description is incomplete. It lacks details on behavior, error handling, and output expectations, leaving significant gaps for an AI agent to understand how to use it effectively.
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%, so the schema fully documents the single parameter 'items' and its nested structure. The description adds no additional meaning beyond implying batch operations, which is already clear from the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update multiple UVMaps in a single operation' clearly states the action (update) and resource (UVMaps), but it's vague about what 'update' entails—does it modify coordinates, metadata, or other properties? It distinguishes from sibling tools like 'createUVMaps' and 'deleteUVMaps' by focusing on updates, but lacks specificity on the scope of changes.
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 is provided. The description implies it's for batch updates, but it doesn't specify prerequisites (e.g., existing UVMaps), exclusions, or when to choose single-update methods if available. Without such context, usage is unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action ('Set properties') without disclosing behavioral traits. It doesn't mention whether this is destructive, requires specific permissions, has rate limits, returns confirmation, or what happens on partial failures. For a mutation tool with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with zero waste. The description is front-loaded with the core action and scope. Every word earns its place - 'Set' (verb), 'properties' (what), 'on multiple objects' (scope).
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 happens after setting properties, whether changes are reversible, what types of objects/properties are supported, or error handling. Given the complexity implied by sibling tools (3D modeling/geometry operations), 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?
Schema description coverage is 100%, so the schema fully documents the 'items' parameter structure. The description adds no additional parameter semantics beyond implying batch operations through 'multiple objects', which aligns with the array structure in the schema. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set properties on multiple objects' clearly states the verb ('Set') and resource ('properties on multiple objects'), but it's vague about what types of objects and properties are involved. It distinguishes from siblings like 'batchGetProperty' (get vs set) and 'setMetadata' (metadata vs properties), but doesn't specify scope beyond 'multiple 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?
No guidance on when to use this tool versus alternatives like 'setMetadata', 'update*' tools, or 'batchSetParent'. The description implies batch operations but doesn't specify prerequisites, limitations, or when to choose this over single-object property setting 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 full burden. 'Apply transformations' implies mutation, but it doesn't disclose behavioral traits like whether this is destructive, requires specific permissions, has side effects, or how errors are handled. The description adds no context beyond the basic action statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized and front-loaded, directly stating the tool's 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?
For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'transformations' entail, what objects are affected, how results are returned, or error conditions. Given the complexity implied by the input schema (with multiple transformation types), more context 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?
Schema description coverage is 100%, so the schema fully documents the single 'items' parameter and its nested properties. The description mentions 'transformations' which aligns with the schema's transformation fields (position, rotation, scale), but adds no additional meaning about parameter usage, constraints, or semantics beyond what's already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Apply transformations to multiple objects' clearly states the action (apply transformations) and target (multiple objects), but it's vague about what types of transformations are involved. It doesn't distinguish from sibling tools like 'transformVertices' or 'transformUVs' which also apply transformations to specific object 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?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools that perform transformations (e.g., transformVertices, transformUVs, batchSetProperty), the description offers no context about appropriate use cases, prerequisites, 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?
No annotations are provided, so the description carries full burden. It mentions the action ('bevel') but doesn't disclose behavioral traits such as whether this is a destructive modification, permission requirements, rate limits, or what the output looks like (e.g., new geometry). 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 extremely concise ('Bevel edges or vertices') with zero wasted words, making it front-loaded and easy to parse. It efficiently states the core action and targets 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 complexity of a geometric modification tool with no annotations and no output schema, the description is incomplete. It doesn't explain what beveling entails, potential side effects, or return values, leaving significant gaps for an AI agent to understand how to use it effectively in context with sibling tools.
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 parameters (e.g., 'items', 'amount', 'edgeIds', 'meshId', 'segments', 'shape', 'vertexIds') with descriptions. The description adds no additional meaning beyond what the schema provides, such as explaining how parameters interact or typical values. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Bevel edges or vertices' states the action (bevel) and target resources (edges/vertices), which is clear but vague. It doesn't specify what beveling does (e.g., creating rounded/chamfered edges) or distinguish from similar operations like 'extrudeFaces' or 'bridge' among siblings. The purpose is understandable but lacks specificity about the geometric transformation.
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 'extrudeFaces' or 'bridge', nor any context about prerequisites (e.g., needing selected edges/vertices). The description implies usage for beveling but offers no explicit when/when-not instructions 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 of behavioral disclosure. 'Create' implies a write operation, but the description doesn't state whether this is idempotent, requires specific permissions, affects existing data, or what happens on failure (e.g., partial creation). It lacks details on return values or error handling, 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 extremely concise with just three words, front-loading the key action and resource. There's no wasted language or redundancy, making it efficient for quick scanning. However, this conciseness comes at the cost of completeness, as noted in other dimensions.
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 creating animation channels with 10 nested parameters per item, no annotations, and no output schema, the description is inadequate. It doesn't explain the context (e.g., 3D animation), relationships to other tools (like 'createClips'), or behavioral aspects. For a mutation tool with rich input schema, more guidance is needed to help the agent use it correctly.
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%, with detailed descriptions for all parameters in the nested 'items' array. The description adds no additional parameter semantics beyond implying bulk creation ('multiple Channels'), which is already evident from the 'items' array structure. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate or add value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create multiple Channels' clearly states the action (create) and resource (Channels), but it's vague about what Channels are in this context (animation channels). It doesn't differentiate from siblings like 'createClips' or 'createKeyframes', which are related animation tools. The purpose is understandable but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing existing clips or nodes), compare to single-channel creation, or explain its role relative to siblings like 'createClips' or 'updateChannels'. Without such context, the agent must infer usage from the schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Create' implies a write operation, but the description doesn't disclose behavioral traits like whether this requires specific permissions, if it's idempotent, what happens on failure, or how many Clips can be created at once. It lacks crucial context 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 extremely concise at three words with no wasted language. It's front-loaded with the core action and resource, making it easy 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?
For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what Clips are, what they're used for, or what the tool returns. Given the complexity implied by the detailed input schema, more context 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?
Schema description coverage is 100%, so the schema fully documents the single parameter 'items' and its nested properties. The description adds no parameter information beyond what's in the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create multiple Clips' states the action (create) and resource (Clips), but is vague about what Clips are in this context and doesn't differentiate from sibling tools like 'createKeyframes' or 'createConstraints'. It lacks specificity about the domain or purpose of Clips.
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. With many sibling tools for creating different resources (e.g., createMaterials, createKeyframes), the description doesn't indicate when Clips are appropriate or what prerequisites might be needed.
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. 'Create' implies a write/mutation operation, but the description doesn't specify permissions required, whether creation is idempotent, error handling for invalid inputs, or what happens on success (e.g., returns IDs). It mentions 'multiple' but doesn't clarify limits or batch behavior. 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 extremely concise with just three words, front-loading the key action and resource. There is no wasted language or redundancy, making it easy to parse quickly. However, this conciseness comes at the cost of completeness, as noted in other dimensions.
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 mutation tool for batch creation with nested parameters), lack of annotations, and no output schema, the description is insufficient. It doesn't explain what Groups are, behavioral aspects like side effects or errors, or what to expect upon success. The agent must rely heavily on the schema and guesswork, which is inadequate for safe and effective tool 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 input schema has 100% description coverage, documenting all parameters (items array with nested properties like name, objectIds, locked, visible, metadata, parentId). The description adds no parameter-specific information beyond implying batch creation via 'multiple', which aligns with the items array in the schema. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create multiple Groups' clearly states the action (create) and resource (Groups), and the plural 'multiple' hints at batch creation. However, it doesn't distinguish this tool from sibling tools like 'createMaterials' or 'createMeshs' beyond the resource type, and it lacks specificity about what Groups are in this context (e.g., 3D modeling groups, organizational groups).
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., existing objects for objectIds), compare it to single-creation tools if any exist, or indicate scenarios where batch creation is preferred. The agent must infer usage solely from the tool name and schema.
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. 'Create' implies a write operation, but it doesn't disclose behavioral traits like whether this requires specific permissions, if it's destructive to existing data, rate limits, or what happens on failure. The description adds no 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?
Extremely concise with just three words. It's front-loaded with the core action and resource, with zero wasted sentences. Every word earns its place by directly stating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (creating multiple IKChains with many nested parameters), no annotations, and no output schema, the description is incomplete. It doesn't explain what IKChains are, their role in animation, expected outcomes, or error handling. For a tool with rich parameter schema but no other structured data, this minimal description leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the single parameter 'items' and its nested properties. The description adds no meaning beyond what the schema provides—it doesn't explain IK chain concepts, relationships between parameters, or usage examples. Baseline 3 is appropriate when schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create multiple IKChains' clearly states the verb ('Create') and resource ('IKChains'), but it's vague about what IKChains are (inverse kinematics chains for animation/rigging) and doesn't differentiate from siblings like 'createJoints' or 'createConstraints'. It's functional but lacks domain-specific clarity.
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. Sibling tools include 'createJoints', 'createConstraints', and 'updateIKChains', but the description doesn't mention prerequisites, dependencies, or scenarios where IKChains are appropriate versus other animation 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. 'Create multiple Layers' implies a write operation, but it doesn't specify if this is destructive (e.g., overwrites existing layers), requires specific permissions, or has side effects like affecting scene hierarchy. It lacks details on error handling or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two words, 'Create multiple Layers', which is front-loaded and wastes no space. It efficiently conveys the core action 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 incomplete. It doesn't explain what 'Layers' are, how they integrate with the system (e.g., relation to clips or hierarchy), or what happens upon creation. Given the complexity implied by parameters like 'additive' and 'parentId', more context 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?
Schema description coverage is 100%, so the schema fully documents the 'items' parameter and its nested properties (e.g., name, additive, clipIds). The description adds no additional meaning beyond implying multiple creation, which is already clear from the parameter name 'items' being an array. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create multiple Layers' clearly states the action (create) and resource (Layers), but it's vague about what 'Layers' are in this context (e.g., animation layers, 3D model layers). It doesn't distinguish from siblings like 'createBlendShapes' or 'createMaterials', leaving ambiguity about the specific domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention if this is for batch creation versus single creation, or prerequisites like needing existing clips or parent layers. The description alone offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 'Delete multiple Clips' but doesn't disclose critical behavioral traits: whether deletion is permanent or reversible, permission requirements, rate limits, error handling for invalid IDs, or confirmation prompts. For a destructive operation with zero annotation coverage, this is a severe 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 with zero waste: 'Delete multiple Clips'. It is front-loaded and appropriately sized, conveying the core action 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 complexity (destructive batch operation), lack of annotations, and no output schema, the description is incomplete. It fails to address safety, consequences, or response format, leaving significant gaps for an AI agent to understand and invoke it correctly in 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%, with the parameter 'ids' documented as 'Clip identifiers to delete'. The description adds no additional parameter semantics beyond this, such as format examples or constraints. With high schema coverage, the baseline is 3, as the description doesn't compensate but doesn't detract either.
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 'Delete multiple Clips' clearly states the action (delete) and resource (Clips), with 'multiple' indicating batch operation. It distinguishes from single-item deletions like deleteBlendShapes or deleteMaterials by specifying multiple items, though not explicitly from other batch tools like batchSetProperty. The purpose is specific but could better differentiate from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 is provided. It doesn't mention prerequisites (e.g., needing clip IDs from getClips or listClips), error conditions, or comparisons to other deletion tools like deleteMaterials. The description assumes context without explicit 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. 'Delete multiple Faces' implies a destructive mutation, but it doesn't disclose whether deletions are permanent, reversible via undo, require specific permissions, or have side effects on related mesh data. For a destructive tool with zero annotation coverage, this is a significant gap in 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 extremely concise with just three words, front-loading the key action and resource. There's zero wasted language, making it easy to parse quickly, though this brevity contributes to gaps in other dimensions.
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, lack of annotations, and no output schema, the description is incomplete. It doesn't address critical context like confirmation prompts, error handling, or return values. For a mutation tool in a 3D modeling context with many sibling alternatives, more guidance is needed to ensure safe and correct usage.
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 the parameter 'ids' clearly documented as 'Face identifiers to delete'. The description adds no additional meaning beyond what the schema provides—it doesn't explain format, constraints, or examples for the identifiers. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete multiple Faces' clearly states the action (delete) and target resource (Faces), but it's vague about scope and lacks differentiation from sibling tools like deleteEdges or deleteVertexs. It doesn't specify what 'Faces' are in this context (e.g., 3D mesh faces) or how this differs from other deletion tools.
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. With sibling tools like deleteEdges, deleteVertexs, and clearSelection available, the description doesn't indicate whether this is for bulk operations, irreversible deletions, or specific use cases. There's no mention of prerequisites or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Delete' implies a destructive mutation, but it doesn't disclose whether deletion is permanent, reversible (e.g., via undo), requires specific permissions, or has side effects on related data. For a destructive tool with zero annotation coverage, this is inadequate behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, front-loaded with the core action. There's zero waste or redundancy, making it efficient for quick scanning, though this conciseness comes at the cost of detail.
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, lack of annotations, and no output schema, the description is incomplete. It doesn't explain what keyframes are, the impact of deletion, error conditions, or return values. For a mutation tool with significant behavioral implications, 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?
Schema description coverage is 100%, with the parameter 'ids' clearly documented as 'Keyframe identifiers to delete'. The description adds no additional meaning beyond what the schema provides, but the baseline is 3 when schema coverage is high (>80%) and no param info is in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete multiple Keyframes' clearly states the verb (delete) and resource (keyframes), but it's vague about scope and doesn't differentiate from sibling tools like deleteKeyframes vs deleteChannels or deleteClips. It doesn't specify what keyframes are in this context or what happens when they're deleted.
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. There's no mention of prerequisites (e.g., needing existing keyframes), consequences of deletion, or comparison to related tools like deleteKeyframes vs updateKeyframes or createKeyframes. The description provides only basic functionality without 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 the action without behavioral details. It doesn't disclose if deletion is destructive, requires permissions, has side effects (e.g., cascading deletions), or provides confirmation. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for the tool's apparent simplicity, though this conciseness comes at the cost of completeness.
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 mutation tool with no annotations and no output schema, the description is incomplete. It lacks critical context like deletion behavior, error handling, return values, or safety warnings. Given the complexity implied by sibling tools (e.g., createLayers, updateLayers), more guidance 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?
Schema description coverage is 100%, with the parameter 'ids' documented as 'Layer identifiers to delete'. The description adds no additional meaning beyond this, such as format examples or constraints (e.g., minimum/maximum IDs). Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete multiple Layers' clearly states the action (delete) and resource (Layers), but it's vague about scope and lacks differentiation from sibling tools like deleteMaterials or deleteMeshs. It doesn't specify if deletion is permanent or reversible, or what constitutes a 'Layer' in this context.
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 layer IDs from getLayers), consequences of deletion, or comparisons to related tools like deleteLayers versus clearSelection or performGroupOperations for layer management.
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. 'Delete multiple Materials' implies a destructive mutation, but it doesn't disclose whether deletion is permanent, reversible, requires specific permissions, affects dependent objects, or has rate limits. For a destructive operation with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just two words. It's front-loaded with the essential action and resource, with zero wasted words. For such a simple tool, this level of brevity is appropriate.
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 destructive mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after deletion, whether there are confirmation prompts, error conditions, or what 'Materials' represent in this system. The context demands more behavioral disclosure.
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 the 'ids' parameter clearly documented as 'Material identifiers to delete'. The description adds no additional parameter semantics beyond what the schema provides, but with complete schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete multiple Materials' clearly states the verb (delete) and resource (Materials), but it's vague about scope and doesn't distinguish from sibling tools like 'deleteMeshes' or 'deleteBlendShapes'. It doesn't specify what 'Materials' are in this context or whether this is a batch operation versus single deletion.
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 is provided. The description doesn't mention prerequisites, permissions needed, or when to choose this over other deletion tools like 'deleteMeshes'. With many sibling deletion tools present, this lack of differentiation is a significant gap.
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. 'Edit' implies a mutation operation, but the description doesn't mention permissions needed, whether changes are destructive or reversible, error conditions, or what happens to other curve properties. For a mutation tool with zero annotation coverage, this is insufficient 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 extremely concise at just 5 words with no wasted language. It's front-loaded with the core action and target. Every word earns its place, making it easy to scan and understand at a glance.
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 inadequate. It doesn't explain what 'editing' entails, what happens after modification, error conditions, or relationship to sibling tools. The 100% schema coverage helps with parameters, but the overall context for using this tool is incomplete.
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 has 100% description coverage, so the baseline is 3. The description doesn't add any parameter information beyond what's already in the schema descriptions for 'items', 'curveId', 'controlPointIndex', 'position', and 'weight'. It doesn't explain relationships between parameters or provide usage examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Edit control points of curves' clearly states the action (edit) and target (control points of curves), but it's somewhat vague about scope and doesn't differentiate from sibling tools like 'updateCurves' or 'transformVertices'. It specifies what's being edited but not the nature or extent of the editing 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 no guidance on when to use this tool versus alternatives. With sibling tools like 'updateCurves', 'transformVertices', and 'createCurves', there's no indication of when this specific control point editing tool is appropriate versus broader curve modification 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 of behavioral disclosure. It states the tool exports geometry but doesn't mention whether this is a read-only operation, if it modifies data, what permissions are needed, or any side effects like file creation. For a tool that likely writes external files, 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 directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, with zero wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that exports geometry (likely involving file creation or data transformation), the description is incomplete. There's no output schema, and with no annotations, it fails to address critical behavioral aspects like what the tool returns, error conditions, or file handling. The schema covers parameters well, but overall context is lacking.
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, documenting all parameters thoroughly. The description adds no additional parameter information beyond what the schema provides. According to the rules, with high schema coverage, the baseline is 3 even without param details in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool exports geometry collections to external formats, which is a clear verb+resource combination. However, it doesn't differentiate from the sibling 'importGeometry' tool, which handles the opposite operation. The purpose is understandable but lacks 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, constraints, or compare it to other export-related operations that might exist in the context. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Get all children') but does not reveal critical traits: whether this is a read-only operation, if it requires specific permissions, how results are returned (e.g., list format, pagination), or potential side effects. For a tool with no annotation coverage, this leaves significant gaps in understanding its 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 ('Get all children of an object') with zero wasted words. It is front-loaded and directly states the core function, making it easy to parse quickly. Every word earns its place, adhering to best practices for brevity in tool descriptions.
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 hierarchical retrieval tool with 3 parameters) and lack of annotations and output schema, the description is incomplete. It does not explain the return format, error conditions, or how 'children' are defined in this system (e.g., 3D objects, nodes). For a tool that likely returns structured data, more context is needed to guide 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?
Schema description coverage is 100%, with clear descriptions for each parameter (e.g., 'Parent object identifier' for 'id'). The description adds no additional meaning beyond the schema, such as explaining the hierarchy context for 'recursive' or examples for 'typeFilter'. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, but the description does not compensate with extra insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all children of an object' clearly states the verb ('Get') and resource ('children of an object'), making the purpose understandable. However, it lacks specificity about what 'children' means in this context (e.g., 3D modeling objects, nodes, or files) and does not differentiate from sibling tools like 'getProperty' or 'getSelection', which also retrieve data but target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a valid object ID), exclusions, or comparisons to similar tools like 'listGroups' or 'getFaces', which might retrieve related hierarchical data. Without such context, the agent must 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?
No annotations are provided, so the description carries full burden. 'Get' implies a read operation, but the description doesn't disclose any behavioral traits: no information about permissions needed, rate limits, whether it returns partial results if some IDs are invalid, error handling, or what format the curves are returned in. For a tool with no annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 4 words ('Get multiple Curves by IDs'), with zero wasted words. It's front-loaded with the core action and immediately specifies the key constraint (by IDs). This is an example of efficient communication where every word 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 complexity (batch retrieval operation), no annotations, and no output schema, the description is incomplete. It doesn't explain what 'Curves' are in this 3D modeling context, doesn't describe the return format, doesn't mention error handling for invalid IDs, and provides no behavioral context. For a tool that presumably returns complex geometry data, this leaves too many questions unanswered.
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% (the 'ids' parameter is fully documented in the schema as 'Curve identifiers'), so the baseline is 3. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain what constitutes a valid Curve ID, whether there are format requirements, or constraints on the array size.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get multiple Curves by IDs' clearly states the verb ('Get') and resource ('Curves'), making the purpose understandable. However, it's somewhat vague about what 'Curves' are in this context (likely 3D modeling curves) and doesn't distinguish this tool from similar siblings like 'getCurves' (which doesn't exist in the list) or 'listCurves' - the sibling 'listCurves' suggests there's a listing operation, making this tool's batch retrieval by IDs less clearly differentiated.
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. There's no mention of when this batch retrieval by IDs is preferable to 'listCurves' (which appears to list all curves) or other get operations like 'getProperty'. No prerequisites, limitations, or comparison with siblings are provided.
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 'Get multiple Edges by IDs', which implies a read operation, but doesn't disclose behavioral traits such as whether it requires specific permissions, how it handles invalid IDs (e.g., errors, skips), rate limits, or what the return format looks like (e.g., array of edge objects). This leaves significant gaps for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Get multiple Edges by IDs'), consisting of a single, front-loaded sentence with zero wasted words. It efficiently communicates the core action and parameter, making it easy 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 the complexity (a read operation with no annotations and no output schema), the description is incomplete. It doesn't explain what 'Edges' are, how results are returned, error handling, or usage context. For a tool with 1 parameter and high schema coverage, it's minimally adequate but lacks necessary behavioral and contextual details to fully guide 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 input schema has 100% description coverage, with the 'ids' parameter documented as 'Edge identifiers'. The description adds no additional meaning beyond this, as it merely restates 'by IDs'. Since schema coverage is high, the baseline score is 3, reflecting adequate but no extra value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get multiple Edges by IDs' clearly states the verb ('Get') and resource ('Edges'), but it's vague about what 'Edges' are in this context (e.g., 3D modeling edges, graph edges). It distinguishes from siblings like 'getFaces' or 'getVertexs' by specifying 'Edges', but doesn't explain how it differs from 'listEdges' (which might list all edges vs. fetching specific ones).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention when to use 'getEdges' (for specific IDs) versus 'listEdges' (for all edges) or other sibling tools like 'getFaces'. The description implies usage by IDs but offers no context on prerequisites 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?
No annotations are provided, so the description carries the full burden. It states 'Get multiple Keyframes by IDs', which implies a read operation, but doesn't disclose behavioral traits such as whether it's safe (non-destructive), requires permissions, has rate limits, returns partial results for invalid IDs, or handles errors. This leaves significant gaps for an agent to understand how to invoke it correctly.
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 no wasted words. It's front-loaded with the core action ('Get multiple Keyframes') and specifies the method ('by IDs'), making it easy to parse quickly. Every part of the sentence serves a purpose in conveying 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 retrieval tool with no annotations and no output schema), the description is incomplete. It doesn't explain what 'get' entails (e.g., returns data, objects, or metadata), how results are structured, or error handling. For a tool that likely returns keyframe data, more context is needed to guide an agent effectively, especially without annotations to fill in behavioral gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'ids' documented as 'Keyframe identifiers'. The description adds minimal value beyond this by mentioning 'by IDs', which aligns with the schema but doesn't provide additional semantics like format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate with extra insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get multiple Keyframes by IDs' clearly states the verb ('Get') and resource ('Keyframes'), but it's vague about scope and doesn't distinguish from siblings like 'getKeyframes' (singular) or 'listKeyframes'. It specifies 'multiple' and 'by IDs' which adds some specificity, but lacks detail about what 'get' entails (e.g., retrieve data vs. fetch 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?
No guidance is provided on when to use this tool versus alternatives like 'listKeyframes' or 'getKeyframes' (if a singular version exists). The description implies usage for retrieving specific keyframes by IDs, but doesn't mention prerequisites, exclusions, or context for choosing it over other retrieval methods.
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 it's a read operation ('Get'), implying it's non-destructive, but doesn't clarify permissions, error handling (e.g., if property doesn't exist), or return format. For a tool with no annotations, this lacks critical details like whether it's safe or has side effects.
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 waste: 'Get a property value from an object'. It's front-loaded and efficiently conveys the core action without unnecessary elaboration, 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 the complexity of a property retrieval tool in a 3D modeling context (inferred from sibling tools), the description is incomplete. With no annotations, no output schema, and many sibling tools, it should specify more about the object domain (e.g., 3D models), property types, or usage context to help the agent understand when and how to invoke it effectively.
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%, with clear descriptions for both parameters ('Object identifier' and 'Path to the property'), so the schema does the heavy lifting. The description adds no additional meaning beyond the schema, such as examples of property paths or object types, but this is acceptable given the high coverage, 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a property value from an object' clearly states the verb ('Get') and resource ('property value from an object'), making the purpose understandable. However, it's vague about what type of object or property is involved (e.g., 3D model, configuration), and it doesn't distinguish this from sibling tools like 'getMetadata' or 'query', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. With many sibling tools like 'getMetadata', 'query', and batch operations (e.g., 'batchGetProperty'), there's no indication of scenarios where this tool is preferred, such as for single property retrieval or specific object types. This leaves the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it's a 'get' operation, implying read-only behavior, but doesn't disclose if it requires specific permissions, what happens if nothing is selected (e.g., returns empty list or error), or any rate limits. The description is minimal and lacks behavioral details.
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 and efficiently conveys the core purpose without unnecessary elaboration, making it easy 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 no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., list of object IDs, names, or full data), error conditions, or dependencies on other tools like 'select'. For a read operation in a complex 3D modeling context, 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 input schema has 100% description coverage, with the 'domain' parameter documented as 'Optional domain to filter results (e.g., 'mesh', 'animation')'. The description doesn't add any meaning beyond this, such as explaining what domains are available or how filtering works. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get currently selected objects' clearly states the action (get) and target (selected objects), but it's vague about what 'objects' means in this context (e.g., 3D models, vertices, materials) and doesn't distinguish from sibling tools like 'getProperty' or 'getMetadata'. It's functional but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention if this is for retrieving selection state after operations like 'select' or 'clearSelection', or how it differs from 'getProperty' for selection-related queries. The description alone offers no 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?
No annotations are provided, so the description carries full burden. It states it's a 'get' operation which implies read-only, but doesn't disclose behavioral traits like whether it returns partial results if some IDs are invalid, what format the UVMaps are returned in, or any rate limits. The description is minimal and lacks crucial 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 extremely concise at just 5 words, with zero wasted language. It's front-loaded with the core purpose and efficiently communicates the essential action. Every word earns its place in this minimal description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and operating in a complex 3D modeling context with many sibling tools, the description is inadequate. It doesn't explain what UVMaps are, what data they contain, how they're returned, or how this differs from list operations. The agent would struggle to use this effectively without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'ids' clearly documented as 'UVMap identifiers' in the schema. The description adds no additional meaning beyond what the schema provides, simply restating 'by IDs'. With high schema coverage, the baseline is 3 even without extra param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get multiple UVMaps by IDs' clearly states the action (get) and resource (UVMaps), but it's vague about scope and doesn't distinguish from siblings like 'getUVMaps' vs 'listUVMaps'. It specifies 'by IDs' which adds some specificity, but doesn't explain what UVMaps are or how this differs from other get operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'listUVMaps' or 'getProperty'. The description implies it's for retrieving specific UVMaps when you know their IDs, but there's no explicit comparison to sibling tools or context about 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 states it 'gets' data (implies read-only), but doesn't disclose behavioral traits like error handling (e.g., invalid IDs), performance (e.g., limits on array size), or output format. The description is minimal and lacks necessary context for safe use.
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 waste. It's front-loaded and appropriately sized for a simple tool, though this conciseness comes at the cost of completeness in other dimensions.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what 'Vertexs' are, how they're returned, or any constraints. For a tool with 1 parameter and no structured output documentation, more context is needed to understand its full behavior and use cases.
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 the 'ids' parameter documented as 'Vertex identifiers'. The description adds no additional meaning beyond this, as it merely restates 'by IDs'. With high schema coverage, the baseline score of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get multiple Vertexs by IDs' clearly states the action (Get) and resource (Vertexs), but it's vague about what 'Vertexs' are in this context (likely 3D mesh vertices). It doesn't distinguish from sibling tools like 'getSelection' or 'listVertexs' which might retrieve vertices differently.
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. Sibling tools include 'getSelection' (gets selected vertices), 'listVertexs' (likely lists all vertices), and 'getVertexs' (gets specific vertices by ID), but the description provides no comparison or context for choosing between them.
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. 'List all Channels' implies a read-only operation but doesn't disclose behavioral traits like pagination behavior (implied by offset/limit parameters), whether results are filtered/sorted, authentication needs, rate limits, or what happens on empty results. The description adds minimal value 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?
Extremely concise with zero waste—a single three-word phrase. It's front-loaded with the core action. Every word earns its place, though this conciseness comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain the return format, error conditions, or how parameters interact. Given the complexity implied by filters and pagination, more context is needed for the agent to use this tool effectively.
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 well-documented in the schema. The description adds no meaning beyond what the schema provides—it doesn't explain how filters work, what parentId refers to, or pagination strategy. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all Channels' clearly states the verb ('List') and resource ('Channels'), but it's vague about scope and doesn't differentiate from sibling tools like 'getChannels'. It doesn't specify what 'all' means in context (e.g., all in workspace, all accessible, all in hierarchy).
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 'getChannels' or other 'list*' tools. The description provides no context about prerequisites, appropriate scenarios, or exclusions. The agent must 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?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'List all Constraints' implies a read-only operation, but it doesn't specify whether this requires permissions, what format the results come in, whether it's paginated (though parameters suggest it might be), or any rate limits. The description adds minimal behavioral context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, with zero wasted language. It's front-loaded with the core action and resource, making it efficient for quick scanning.
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 list operation with four parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'Constraints' are in this 3D modeling context, what the output looks like, or how the filtering/pagination works. The description leaves too many questions unanswered for proper tool selection.
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 four parameters (filters, limit, offset, parentId) with descriptions. The tool description adds no parameter information beyond what's in the schema, meeting the baseline of 3 when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all Constraints' clearly states the verb ('List') and resource ('Constraints'), making the basic purpose understandable. However, it doesn't differentiate this tool from similar sibling tools like 'getConstraints' or explain what 'Constraints' are in this context, leaving the purpose somewhat vague.
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. With sibling tools like 'getConstraints' and 'deleteConstraints' available, there's no indication of whether this tool is for listing all constraints versus getting specific ones, or how it differs from other list operations in the server.
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. 'List all Drivers' implies a read-only operation, but it doesn't specify whether this is safe, if it requires authentication, what the output format is, or any rate limits. For a tool with no annotations, this minimal description fails to provide essential behavioral context, though it doesn't contradict anything.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, 'List all Drivers', which is front-loaded and wastes no space. Every word contributes to the core purpose, making it efficient and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a list operation with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'Drivers' are, how results are returned, or any behavioral traits, leaving significant gaps. The high schema coverage helps with parameters, but overall context is lacking for effective tool 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 input schema has 100% description coverage, with clear documentation for all 4 parameters (filters, limit, offset, parentId). The description adds no parameter semantics beyond what the schema provides, such as examples or usage tips. According to the rules, with high schema coverage (>80%), the baseline score is 3, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all Drivers' clearly states the verb ('List') and resource ('Drivers'), providing a basic purpose. However, it lacks specificity about what 'Drivers' are in this context (e.g., 3D modeling drivers, device drivers) and doesn't differentiate from sibling tools like 'getDrivers' or 'createDrivers', making it somewhat vague. It's not tautological but could be more precise.
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 any prerequisites, context for use, or compare it to similar tools like 'getDrivers' or 'query', leaving the agent with no usage instructions. This is a significant gap in helping the agent make informed decisions.
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 for behavioral disclosure. 'List all Edges' implies a read-only operation but doesn't specify permissions, rate limits, pagination behavior (beyond schema hints), or output format. For a tool with 4 parameters and no output schema, this is insufficient to inform safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with 'List all Edges'—three words that directly convey the core action. It's front-loaded with zero wasted words, making it efficient for quick comprehension. This is a model of brevity in tool descriptions.
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 (4 parameters, nested objects, no output schema) and lack of annotations, the description is incomplete. It doesn't explain return values, error conditions, or behavioral nuances like how 'filters' work with 'parentId'. For a list operation with filtering and pagination, more context 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?
Schema description coverage is 100%, so parameters are well-documented in the schema itself. The description adds no additional meaning beyond implying filtering via 'all Edges', which loosely relates to 'filters' and 'parentId'. Baseline 3 is appropriate as the schema does the heavy lifting, but the description doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all Edges' clearly states the verb ('List') and resource ('Edges'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'getEdges' or 'listFaces', leaving ambiguity about scope or method. It's adequate but lacks specificity about what distinguishes this listing 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?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools (e.g., 'getEdges', 'listFaces', 'query'), the description offers no context about prerequisites, typical use cases, or comparisons. This leaves the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List all Faces' implies a read-only operation but doesn't specify whether it's paginated (though parameters suggest it might be), what format the results take, or if there are performance considerations. For a tool with 4 parameters and no output schema, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, with zero wasted language. It's front-loaded with the core action ('List all Faces'), making it immediately understandable. Every word earns its place, though this brevity comes at the cost of completeness.
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 (4 parameters, no annotations, no output schema, many sibling tools), the description is inadequate. It doesn't explain what 'Faces' are in this context (3D modeling faces vs. other types), how results are structured, or how this differs from similar tools. For a listing operation in what appears to be a 3D modeling system, more context 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 schema description coverage is 100%, with clear documentation for all 4 parameters (filters, limit, offset, parentId). The description adds no parameter information beyond what's in the schema, so it meets the baseline of 3. However, it doesn't compensate by explaining how parameters interact (e.g., how filters combine with parentId) or provide examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all Faces' clearly states the verb ('List') and resource ('Faces'), making the basic purpose understandable. However, it doesn't distinguish this tool from similar sibling tools like 'getFaces' or 'list' operations for other resources (e.g., 'listEdges', 'listVertexs'), leaving ambiguity about what makes this specific listing operation unique.
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. With sibling tools like 'getFaces' (which might retrieve specific faces) and 'query' (which might offer more flexible searching), there's no indication of when this listing approach is preferred or what its limitations are. The agent must 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 full burden but only states the basic action. It doesn't disclose whether this is a read-only operation, what permissions might be needed, whether results are paginated, or what format the output takes. Significant behavioral context is missing for a tool with 4 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?
The description is extremely concise at just three words with zero wasted language. It's front-loaded with the core action and resource, making it efficient despite its simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what IKChains are, what the output looks like, or how to effectively use the filtering and pagination parameters. The minimal description leaves too much unexplained.
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 well-documented in the schema. The description adds no additional parameter information beyond implying some filtering capability through 'all IKChains', which doesn't provide meaningful semantics beyond what the schema already specifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all IKChains' clearly states the verb ('List') and resource ('IKChains'), but it's vague about scope and doesn't differentiate from sibling tools like 'getIKChains'. It provides basic purpose but lacks specificity about what 'all' means in context.
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 about when to use this tool versus alternatives like 'getIKChains' or other list operations. The description offers no context about prerequisites, typical use cases, or comparison 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 full burden for behavioral disclosure. 'List all Keyframes' implies a read-only operation but doesn't specify permissions, rate limits, pagination behavior, or what 'all' means in practice. It lacks critical context for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, front-loading the core purpose without any wasted text. It's appropriately sized for a simple list operation, though this brevity contributes to gaps in other dimensions.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what Keyframes are, how results are returned, or behavioral traits. For a tool with four parameters and complex sibling tools, more context 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?
Schema description coverage is 100%, so the schema fully documents all four parameters. The description adds no parameter information beyond what's in the schema, meeting the baseline but not providing extra value. No parameters are required, which is implied but not stated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all Keyframes' clearly states the verb ('List') and resource ('Keyframes'), making the basic purpose understandable. However, it doesn't differentiate from sibling tools like 'getKeyframes' or explain what 'Keyframes' are in this context, leaving some ambiguity about scope.
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 'getKeyframes' or other list tools. There's no mention of prerequisites, context, or comparison with sibling operations, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it's a list operation, implying it's read-only and non-destructive, but doesn't mention pagination behavior (implied by 'limit' and 'offset' parameters), potential performance impacts, error conditions, or return format. For a tool with 4 parameters and no output schema, 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.
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 resource, making it easy to parse quickly. No structural issues or redundancy are present.
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 4 parameters, no annotations, no output schema, and a sibling tool ('getSubdivisionSurfaces'), the description is incomplete. It doesn't explain what 'SubdivisionSurfaces' are, how they differ from other resources, or provide enough context for an agent to use it effectively without trial and error. The minimal description fails to compensate for the lack of structured data.
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 parameter descriptions in the schema (e.g., 'Optional filters to apply', 'Maximum number of results'). The description adds no additional meaning beyond what the schema provides, such as explaining filter types or pagination context. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all SubdivisionSurfaces' clearly states the verb ('List') and resource ('SubdivisionSurfaces'), making the basic purpose understandable. However, it doesn't distinguish this tool from its sibling 'getSubdivisionSurfaces' or explain what 'SubdivisionSurfaces' are in this context, leaving room for ambiguity about scope and 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 like 'getSubdivisionSurfaces' or other list operations. It lacks context about prerequisites, typical use cases, or any exclusions, leaving the agent to infer usage from the 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?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Query' implies a read operation, but the description doesn't clarify whether this is safe (non-destructive), what permissions might be needed, whether results are paginated (though schema hints at this), what format results return, or any rate limits. For a query tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 4 words with zero wasted language. It's front-loaded with the core purpose and appropriately sized for what it communicates. While it could benefit from more detail, what's present is efficiently structured without redundancy or 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 complexity of a query tool in a 3D modeling context with 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'entities' means in this domain, what query capabilities exist, what results look like, or how this integrates with the many specific retrieval tools in the sibling list. For a general query tool in a specialized domain, 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?
Schema description coverage is 100%, so all parameters are documented in the schema itself. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain how 'properties' matching works, what entity 'types' are available, or provide examples of query criteria. With complete schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Query entities based on criteria' states a general purpose (querying entities) but is vague about what 'entities' refers to in this 3D modeling context. It doesn't specify what types of entities (meshes, vertices, materials, etc.) can be queried or how this differs from sibling tools like 'getProperty', 'getSelection', or various 'list' tools. The description provides a basic verb+object but lacks specificity and sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With numerous sibling tools for retrieving specific entity types (getMaterials, listVertices, getSelection, etc.), there's no indication whether this is a general-purpose query tool that replaces those, a complementary tool, or when one would choose this over more specific retrieval tools. No context, prerequisites, or exclusions 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Rename an entity' implies a mutation operation, but it doesn't disclose whether this requires specific permissions, whether the rename is reversible, what happens to references to the old name, 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 extremely concise with just three words ('Rename an entity'), which is front-loaded and wastes no space. Every word earns its place by conveying the core action and target, though it could benefit from additional context.
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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what types of entities can be renamed, the effect of the rename, error conditions, or return values. With many sibling tools that handle specific entities, this lack of context makes it inadequate for safe and 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?
Schema description coverage is 100%, with clear descriptions for both parameters ('id' as 'Entity identifier' and 'name' as 'New name'). The description doesn't add any meaning beyond what the schema provides—it doesn't explain what constitutes a valid entity ID or name format. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Rename an entity' clearly states the verb (rename) and resource (entity), but it's vague about what type of entity is being renamed. It doesn't distinguish from sibling tools like 'updateMaterials' or 'updateMeshs' which might also rename specific entity types. The purpose is understandable but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools that update specific entity types (e.g., updateMaterials, updateMeshs), the description doesn't indicate whether this is a general-purpose rename tool or if it applies to specific entities. There's no mention of prerequisites, exclusions, or alternatives.
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 for behavioral disclosure. 'Set' implies a mutation operation, but the description doesn't specify whether this creates new creases or modifies existing ones, what permissions are needed, whether the operation is destructive to existing geometry, or what happens on failure. For a mutation tool with zero annotation coverage, this is inadequate 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 extremely concise at just 4 words, with zero wasted language. It's front-loaded with the core action and target. While it may be too brief for complete understanding, every word contributes directly to the tool's purpose without redundancy or 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 edge creasing does in 3D modeling, what the expected outcome is, whether the operation is reversible, or what errors might occur. Given the complexity implied by the sibling tools list (3D modeling operations) and the lack of structured behavioral information, the description should provide more context about this specific operation.
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%, with the single 'items' parameter well-documented in the schema as an array of edge crease operations with edgeId and creaseWeight. The description adds no parameter information beyond what the schema provides, but since schema coverage is complete, the baseline score of 3 is appropriate. The description doesn't explain what creaseWeight values mean in practical terms.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set crease weights for edges' clearly states the action (set) and target (crease weights for edges), but it's somewhat vague about what 'crease weights' are in this 3D modeling context. It doesn't differentiate from sibling tools like 'updateEdges' or 'bevel', which might have overlapping functionality. The purpose is understandable but lacks specificity about the modeling 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 no guidance on when to use this tool versus alternatives. With many sibling tools for edge manipulation (updateEdges, bevel, createEdges, deleteEdges, etc.), there's no indication of when edge creasing is appropriate versus other edge operations. The description doesn't mention prerequisites, constraints, 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, the description carries full burden but lacks behavioral details. It doesn't disclose whether this is a destructive mutation (likely, given 'transform'), what permissions are needed, how errors are handled (e.g., invalid vertex IDs), or the expected output format. The description implies a write operation but provides no safety or 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 a single, efficient sentence with no wasted words. It's front-loaded and directly states the tool's function, making it easy to parse quickly, though this conciseness comes at the cost of detail.
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 complex mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain the transformation's effect (e.g., overwriting vs. adjusting UVs), error conditions, or return values, leaving significant gaps for the agent to navigate without structured support.
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 no additional meaning beyond the schema's details about UV channels, mesh IDs, and vertex transformations, meeting the baseline for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Transform UV coordinates for vertices' states the action and target, but is vague about scope and mechanism. It doesn't specify whether this applies to selected vertices, all vertices, or specific meshes, nor does it distinguish from sibling tools like 'transformVertices' or 'unwrapUVs' which might handle different transformations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., existing UV maps), exclusions, or compare it to similar tools like 'transformVertices' (for 3D coordinates) or 'unwrapUVs' (for UV unwrapping), leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. 'Undo the last operation' implies a mutation that reverses a previous action, but it fails to describe critical aspects: whether it's destructive (e.g., overwrites data), requires specific permissions, has side effects (e.g., affects selection state), or handles edge cases (e.g., what happens if no operation exists). The description is too minimal to inform safe or effective use.
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 ('Undo'), making it immediately understandable. This efficiency earns a top score 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 complexity of an undo tool (a mutation with potential side effects), no annotations, and no output schema, the description is incomplete. It lacks details on behavior, return values, error conditions, and interaction with sibling tools like 'redo'. For a tool that modifies state, this minimal description is inadequate for safe agent invocation.
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, meaning no parameters are documented in the schema. The description doesn't add parameter details, which is appropriate since there are none to explain. A baseline of 4 is applied for zero parameters, as the description doesn't need to compensate for missing schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Undo the last operation' clearly states the verb ('undo') and target ('the last operation'), making the purpose understandable. However, it lacks specificity about what constitutes an 'operation' in this context (e.g., modeling actions, edits, transformations) and doesn't differentiate from its sibling 'redo', which is a closely related tool in the list. This vagueness prevents a higher score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., requires a prior operation to undo), exclusions (e.g., cannot undo certain irreversible actions), or comparisons to sibling tools like 'redo' for reversing the undo. This absence of usage context leaves the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Update multiple Channels' which implies a mutation operation, but doesn't disclose critical behavioral traits: whether this requires specific permissions, if changes are reversible, what happens on partial failures, or rate limits. For a batch 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 with zero waste—'Update multiple Channels in a single operation' is front-loaded and appropriately sized. It conveys the core purpose without unnecessary elaboration, earning full marks 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 (batch mutation of animation channels with a nested parameter structure), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'Channels' are, the scope of updates (e.g., can it modify all properties?), error handling, or expected outcomes. For a tool with rich input schema but no other structured data, 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?
Schema description coverage is 100%, so the schema fully documents the single parameter ('items') and its nested properties. The description adds no parameter semantics beyond what's in the schema—it doesn't explain the structure of 'items', provide examples, or clarify relationships between fields like 'clipId' and 'ids'. Baseline 3 is appropriate when the schema does all the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update multiple Channels in a single operation' clearly states the verb ('Update') and resource ('Channels'), and specifies it handles multiple items. However, it doesn't distinguish this from sibling tools like 'updateKeyframes' or 'updateClips'—it's vague about what 'Channels' are in this context (animation channels based on schema) and how this differs from other update operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., existing channels to update), compare it to single-channel updates (if any), or specify scenarios where batch updating is preferred over individual operations. With many sibling tools including 'createChannels' and 'deleteChannels', the lack of context leaves the agent guessing.
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 cover critical aspects like whether it requires specific permissions, if changes are reversible, error handling for invalid IDs, or rate limits. For a batch 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: 'Update multiple Clips in a single operation.' It's front-loaded with the core action and resource, with no wasted words. Every part of the sentence earns its place by specifying the operation type, target, and batch nature.
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 batch update tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., side effects, error handling), usage context, and output expectations. While the schema covers parameters well, the overall context for safe and effective use is insufficient, especially for a mutation operation.
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%, with the single parameter 'items' well-documented as an array of Clips to update with IDs. The description adds no additional parameter semantics beyond what the schema provides—it doesn't explain the structure of items, default behaviors, or constraints. Given high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't need to heavily.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update multiple Clips in a single operation' clearly states the verb ('update') and resource ('Clips'), and specifies it's a batch operation ('multiple...in a single operation'). However, it doesn't distinguish this from sibling tools like 'updateBlendShapes' or 'updateMaterials'—it only clarifies it's for Clips specifically, not how it differs from other update operations. This makes the purpose clear but not fully differentiated from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 existing Clips), compare it to single-update methods, or specify scenarios where batch updating is preferred. With many sibling tools including 'updateClips' and others like 'createClips' or 'deleteClips', the lack of context leaves the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Update multiple Edges', implying a mutation operation, but doesn't mention permissions, side effects, error handling, or response format. This is inadequate for a tool that modifies data without any structured safety hints.
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 no wasted words. It front-loads the key information ('Update multiple Edges') and adds necessary context ('in a single operation'), making it easy 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 the complexity of updating multiple edges (a mutation operation), no annotations, and no output schema, the description is insufficient. It lacks details on behavioral traits, error conditions, and what the tool returns, leaving significant gaps for an AI agent to use it correctly.
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%, so the input schema fully documents the 'items' parameter and its nested properties. The description adds no additional parameter details beyond implying batch processing ('multiple Edges', 'single operation'), which is already evident from the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Update multiple Edges') and scope ('in a single operation'), which clarifies the verb and resource. However, it doesn't distinguish this tool from sibling tools like 'updateEdges' (if it exists) or 'updateFaces', 'updateVertexs', etc., leaving ambiguity about when to use this specific update tool versus others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description mentions 'multiple Edges' and 'single operation', but it doesn't specify prerequisites, exclusions, or compare it to sibling tools like 'updateFaces' or 'updateVertexs', 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 provided, the description carries full burden but offers minimal behavioral insight. It implies a write operation ('Update') but doesn't disclose permissions needed, whether changes are destructive, error handling, or response format. For a mutation tool with zero annotation coverage, 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.
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 and directly states the core functionality 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 incomplete. It doesn't explain what 'update' entails (which properties are mutable), success/failure behavior, or return values. Given the complexity implied by the detailed input schema, 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?
Schema description coverage is 100%, so the schema fully documents the single parameter 'items' and its nested properties. The description adds no parameter details beyond implying batch operation, which the schema already shows via the array structure. Baseline 3 is appropriate when schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update multiple Faces in a single operation' clearly states the verb ('Update') and resource ('Faces'), but it's vague about what specific properties can be updated. It doesn't distinguish from siblings like 'updateMeshs' or 'updateVertexs' beyond specifying the resource type.
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., existing faces), compare to single-face updates, or explain why batch updating is beneficial. The description only states what it does, not when to choose it.
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 'update' which implies mutation, but doesn't disclose behavioral traits such as required permissions, whether updates are atomic or partial, error handling for invalid IDs, or impact on related data (e.g., animation curves). This leaves significant gaps for a mutation tool with complex nested 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?
The description is a single, efficient sentence with zero waste—it's front-loaded and directly states the core functionality. Every word earns its place, making it appropriately sized for 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 complexity (mutation tool with nested parameters, no annotations, no output schema), the description is incomplete. It lacks behavioral context (e.g., side effects, error modes), usage guidelines, and output expectations. For a tool that modifies multiple keyframes with detailed input schema, more context is needed to guide effective agent 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 schema description coverage is 100%, with detailed descriptions for all nested parameters (e.g., 'time', 'value', 'tangentIn'). The description adds no additional meaning beyond the schema—it doesn't explain parameter interactions, constraints, or usage examples. With high schema coverage, the baseline is 3, as the description doesn't compensate but doesn't detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update multiple Keyframes in a single operation' clearly states the verb ('Update') and resource ('Keyframes'), but it's vague about what 'update' entails—it doesn't specify which attributes can be modified (e.g., time, value, tangents). It distinguishes from 'createKeyframes' and 'deleteKeyframes' by implying modification of existing items, but doesn't differentiate from other update tools like 'updateChannels' or 'updateJoints' in terms of scope or behavior.
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 existing keyframes), compare to single-update methods, or specify scenarios like batch efficiency. The context is implied as bulk operations, but no explicit when/when-not rules or sibling tool references are 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?
No annotations are provided, so the description carries full burden. It mentions 'update' implying mutation but doesn't disclose behavioral traits like permission requirements, whether updates are destructive or additive, error handling, or response format. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to scan. Every word earns its place without redundancy.
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 lacks details on behavioral context (e.g., what happens on failure, side effects), and while the schema covers inputs, the overall tool purpose and usage remain under-specified given the complexity implied by sibling tools.
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 'items' parameter and its nested properties. The description adds no additional meaning beyond implying batch operation, which is already clear from the schema's array structure. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Update') and resource ('Layers') with a scope hint ('multiple...in a single operation'), but it's vague about what specific properties can be updated. It doesn't distinguish from siblings like 'updateMaterials' or 'updateClips' beyond the resource name.
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., existing layers), exclusions, or compare with single-update operations if they exist. The context is implied by the name but not explicitly stated.
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. 'Update' implies mutation, but it doesn't disclose: whether this requires specific permissions, if changes are destructive/reversible, rate limits, error handling for invalid IDs, or what happens to unspecified properties. The batch nature is mentioned but without behavioral details.
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?
Single sentence, zero waste - 'Update multiple Vertexs in a single operation' is maximally concise. Every word earns its place, though this conciseness comes at the cost of completeness.
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 inadequate. It doesn't explain what 'Vertexs' are, what 'update' entails, return values, error conditions, or how this differs from similar tools. The 100% schema coverage helps with parameters but doesn't compensate for missing behavioral 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 fully documents the 'items' parameter and its nested properties. The description adds no parameter information beyond what's in the schema - no syntax examples, format clarifications, or usage patterns. Baseline 3 is appropriate when schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Update multiple Vertexs') and resource ('Vertexs'), but it's vague about what 'Vertexs' are in this context (3D modeling vertices?). It doesn't differentiate from sibling tools like 'updateMeshs' or 'transformVertices' - the 'multiple in a single operation' aspect is somewhat distinguishing but not clearly contrasted with 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?
No guidance on when to use this tool versus alternatives like 'updateMeshs', 'transformVertices', or 'batchSetProperty'. The description mentions 'multiple Vertexs in a single operation' which implies batch efficiency, but doesn't specify use cases, prerequisites, 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 full burden but only states what the tool does, not how it behaves. It doesn't disclose whether this is a destructive mutation, what permissions are needed, how errors are handled, or what happens to existing material assignments. For a mutation tool with zero annotation coverage, 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.
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 every word count.
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 the tool returns, how to interpret results, error conditions, or behavioral constraints. The context demands more completeness for safe and 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?
Schema description coverage is 100%, so the schema fully documents the 'items' parameter and its nested structure. The description adds no parameter information beyond what's in the schema, maintaining the baseline score of 3 for adequate schema coverage.
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 ('assign') and target resources ('materials to meshes or specific faces'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'updateMaterials' or 'createMaterials', which might handle related material operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, when to choose face-level versus mesh-level assignment, or how this relates to sibling tools like 'createMaterials' or 'updateMaterials'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Get') but doesn't mention whether this is a read-only operation, what permissions are required, how errors are handled, or the format of returned values. For a tool that presumably reads data from multiple objects, this leaves significant gaps in understanding its 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 directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that reads property values from multiple objects with no annotations and no output schema, the description is insufficient. It doesn't explain what types of objects or properties are supported, what the return format looks like, or any limitations (e.g., maximum batch size). Given the complexity of batch operations and lack of structured documentation, 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 schema description coverage is 100%, so the schema already documents both parameters ('items' and 'recursive') thoroughly. The description doesn't add any additional meaning beyond what the schema provides about these parameters, which is acceptable given the comprehensive schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('property values from multiple objects'), making the purpose understandable. However, it doesn't distinguish this tool from its sibling 'getProperty' (which appears to fetch from a single object), missing an opportunity for explicit 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?
No guidance is provided on when to use this tool versus alternatives like 'getProperty' (for single objects) or other query tools. The description implies batch operations but doesn't specify scenarios or prerequisites for using this multi-object approach.
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 'Set parent' which implies a mutation operation, but doesn't disclose behavioral traits like whether it requires specific permissions, if changes are reversible (e.g., via 'undo'), what happens on failure (e.g., partial updates), or rate limits. For a batch mutation tool with zero annotation coverage, this is a significant gap in safety and 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 a single, efficient sentence with zero waste: 'Set parent for multiple objects'. It's front-loaded and appropriately sized for the tool's complexity, earning its place 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 complexity (batch mutation tool), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'objects' refer to (e.g., in a 3D context), the impact of reparenting (e.g., on transforms or hierarchies), or return values. For a tool that modifies multiple items, more context is needed to ensure safe and correct usage.
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 'items' (parent assignments) and 'maintainWorldTransform' (preserve world transforms). The description adds no parameter semantics beyond the schema, but since the schema does the heavy lifting, the baseline score of 3 is appropriate. No additional value is provided in the description.
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 'Set parent for multiple objects' clearly states the action (set parent) and scope (multiple objects), which distinguishes it from tools like 'getChildren' or 'createGroups'. However, it doesn't specify what type of objects (e.g., 3D objects, meshes, groups) or differentiate from similar batch operations like 'batchSetProperty' beyond the parent-specific action.
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., existing objects), when not to use it (e.g., for single objects), or compare to sibling tools like 'batchTransform' or 'createGroups' for hierarchical operations. The description alone offers no 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?
No annotations are provided, so the description carries the full burden. 'Clear' implies a mutation (likely destructive), but it doesn't disclose behavioral traits such as whether this action is reversible (e.g., with 'undo'), requires specific permissions, or has side effects. The description is minimal and lacks 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 extremely concise ('Clear current selection') with no wasted words, making it front-loaded and easy to parse. Every word earns its place, though this brevity contributes to gaps in other dimensions.
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 mutation tool in a 3D modeling context with many sibling tools), no annotations, and no output schema, the description is incomplete. It lacks details on what 'selection' entails, how clearing interacts with other operations, or what happens post-clear. The minimal description doesn't provide enough context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'domain' well-documented in the schema. The description doesn't add any parameter semantics beyond what the schema provides, but with 0 required parameters and high schema coverage, the baseline is 3. Since the tool has only one optional parameter, a score of 4 reflects that the description doesn't need to compensate for parameter gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Clear current selection' states a specific action (clear) on a resource (selection), but it's vague about what 'selection' means in this 3D modeling context and doesn't distinguish from sibling tools like 'select' or 'getSelection'. It's better than a tautology but lacks specificity about the selection scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an active selection), exclusions, or relationships to sibling tools like 'select' (for setting selection) or 'getSelection' (for retrieving it).
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 tool performs a combination operation but doesn't mention whether this is destructive (e.g., whether original meshes are preserved or deleted), what permissions are needed, error conditions, or what the output looks like. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for the tool's complexity and front-loads the core purpose immediately.
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 to the original meshes, what the combined mesh output contains, or potential side effects. Given the complexity of mesh operations and lack of structured behavioral data, 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?
Schema description coverage is 100%, so the schema already fully documents all four parameters (meshIds, name, preserveSubMeshes, worldSpace). The description adds no additional parameter context beyond what's in the schema, so it meets the baseline for high schema coverage.
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 ('combine') and resource ('multiple meshes into a single mesh'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'splitMeshes' or 'duplicate', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'splitMeshes' for the opposite operation, 'duplicate' for copying without combining, or other mesh manipulation tools. There's no mention of prerequisites, typical use cases, 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 action is deletion (implying destructive mutation) but lacks details on permissions, reversibility (e.g., via 'undo'), side effects, or error handling. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It is appropriately sized and front-loaded, directly stating the tool's 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?
For a destructive mutation tool with no annotations and no output schema, the description is incomplete. It lacks critical context like behavioral traits (e.g., permanence, error responses) and usage guidelines, making it insufficient for safe and effective agent invocation.
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 the parameter 'ids' documented as 'BlendShape identifiers to delete'. The description adds no additional meaning beyond this, such as format examples or constraints. Baseline 3 is appropriate since 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 ('Delete') and target resource ('multiple BlendShapes'), providing specific verb+resource. It distinguishes from siblings like 'getBlendShapes' and 'updateBlendShapes' by focusing on deletion, though it doesn't explicitly differentiate from other delete operations (e.g., 'deleteChannels', 'deleteMaterials').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., existing BlendShapes), exclusions, or comparisons to siblings like 'listBlendShapes' for identification or 'updateBlendShapes' for modification, leaving usage context unclear.
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. 'Delete' clearly indicates a destructive operation, but the description doesn't specify whether deletion is permanent/reversible, what permissions are required, whether there are confirmation prompts, or what happens to dependent data. For a destructive batch operation with zero annotation coverage, this is a significant gap in 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 maximally concise at three words, front-loading the essential information (delete operation, multiple items, resource type). There is zero waste or redundancy. Every word earns its place in communicating the core functionality.
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 batch operation with no annotations and no output schema, the description is incomplete. It doesn't address critical context like deletion consequences, error handling, permissions, or what constitutes valid 'Channels' in this system. The combination of destructive operation + batch capability + zero safety annotations requires more comprehensive description than provided.
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 the single parameter 'ids' documented as 'Channel identifiers to delete'. The description adds no additional parameter information beyond what the schema provides. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, though the description could have provided context about valid ID formats or deletion constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete multiple Channels' clearly states the action (delete) and resource (Channels), with 'multiple' indicating batch operation. It distinguishes from sibling tools like 'deleteChannels' vs 'deleteMaterials' by specifying the resource type. However, it doesn't explain what 'Channels' are in this context, leaving some ambiguity about the exact resource being deleted.
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. There are many sibling deletion tools (deleteMaterials, deleteMeshes, etc.) but no indication of when Channels specifically should be deleted versus other resources. No prerequisites, exclusions, or alternative approaches 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?
No annotations are provided, so the description carries the full burden. It states the tool deletes multiple constraints, implying a destructive operation, but doesn't disclose critical behavioral traits such as whether deletion is permanent, requires specific permissions, has side effects (e.g., affecting related objects), or returns confirmation. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, front-loading the key action and resource. There is zero waste or redundancy, making it efficient for quick understanding, though it may be overly terse for clarity.
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 destructive operation with no annotations and no output schema), the description is incomplete. It lacks information on behavior, output, error handling, or context (e.g., what happens if some IDs are invalid). For a deletion tool, this leaves significant gaps for the agent to operate safely and effectively.
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 schema description coverage is 100%, with the parameter 'ids' clearly documented as 'Constraint identifiers to delete'. The description adds no additional parameter information beyond the schema, but since there's only one parameter and the schema fully covers it, the baseline is high. No compensation is needed, but no extra value is added either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete multiple Constraints' clearly states the action (delete) and resource (Constraints), but it's vague about what 'Constraints' are in this context (e.g., 3D modeling constraints, database constraints). It distinguishes from siblings like 'deleteMaterials' or 'deleteKeyframes' by specifying the resource type, but lacks specificity about the domain or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention prerequisites (e.g., constraints must exist), when not to use it (e.g., if constraints are in use), or alternatives like 'updateConstraints' for modification instead of deletion. The agent must infer usage from the 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?
No annotations are provided, so the description carries full burden. It states 'Delete multiple Curves', implying a destructive mutation, but lacks details on permissions, reversibility (e.g., via 'undo'), side effects, or error handling. For a deletion tool with zero annotation coverage, this is a significant gap in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste: 'Delete multiple Curves'. It is front-loaded and appropriately sized for the tool's purpose, making it easy 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 the tool's complexity (destructive deletion with no annotations and no output schema), the description is incomplete. It lacks information on behavioral traits, return values, or error conditions. For a mutation tool, this leaves significant gaps for an AI agent to understand proper invocation and outcomes.
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 the parameter 'ids' documented as 'Curve identifiers to delete'. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
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 'Delete multiple Curves' clearly states the action (delete) and resource (Curves), with 'multiple' indicating batch capability. It distinguishes from sibling tools like 'deleteEdges' or 'deleteFaces' by specifying the resource type. However, it doesn't explicitly differentiate from 'deleteCurves' (singular) if such a tool existed, though siblings show only this plural version.
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., whether curves must exist or be selected), exclusions, or comparisons to similar tools like 'delete' (general) or 'clearSelection'. The description is purely functional without contextual advice.
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 'Delete multiple Drivers' which implies a destructive mutation, but doesn't disclose critical behavioral traits: whether deletion is permanent/reversible, what permissions are required, if there are side effects (e.g., breaking dependencies), or rate limits. For a destructive tool with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, front-loading the essential action and resource. There's zero wasted language, making it efficient for quick comprehension, though this conciseness comes at the cost of completeness.
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 destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what Drivers are, the consequences of deletion, error conditions, or return values. For a tool that permanently removes resources, more context is needed to use it safely and effectively.
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% with one parameter 'ids' described as 'Driver identifiers to delete'. The description adds no additional parameter information beyond what the schema provides. With high schema coverage and only one parameter, the baseline is high, but the description doesn't compensate with format examples or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete multiple Drivers' clearly states the action (delete) and resource (Drivers), but it's vague about what 'Drivers' are in this context. It distinguishes from sibling tools like 'deleteBlendShapes' or 'deleteMaterials' by specifying the resource type, but doesn't explain what Drivers represent in this system.
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 about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing existing Drivers), what happens after deletion, or when to use batch deletion versus individual deletion. Sibling tools include 'getDrivers' and 'listDrivers' which might be used first, but this isn't stated.
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. 'Delete multiple Edges' implies a destructive mutation, but it doesn't disclose critical behavioral traits: whether deletion is permanent/undoable, what permissions are needed, if there are rate limits, or what happens to connected geometry. This is inadequate for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words with zero wasted language. It's front-loaded with the core action and resource. Every word earns its place, though this conciseness comes at the cost of completeness.
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 deletion tool with no annotations and no output schema, the description is severely incomplete. It doesn't explain what 'Edges' are, the consequences of deletion, error conditions, or return values. Given the complexity of 3D modeling operations and lack of structured data, this leaves critical 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?
Schema description coverage is 100% with one parameter 'ids' documented as 'Edge identifiers to delete'. The description adds no additional parameter semantics beyond what the schema provides. With 0 parameters requiring extra explanation, the baseline is 4 as the schema fully covers the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete multiple Edges' clearly states the action (delete) and resource (Edges), but it's vague about what 'Edges' are in this context (likely 3D modeling edges). It doesn't distinguish from sibling deletion tools like deleteFaces or deleteVertexs beyond naming the resource type.
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 about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., whether edges must be selected first), constraints, or what happens after deletion. With many sibling deletion tools, this lack of differentiation is problematic.
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 'Delete' implying a destructive mutation, but lacks details on permissions, reversibility (e.g., via undo), side effects, error handling, or what happens to associated data. This is inadequate for a destructive 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?
Extremely concise with three words, front-loaded with the verb 'Delete'. No wasted words or redundant information, making it easy 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?
For a destructive mutation tool with no annotations and no output schema, the description is insufficient. It doesn't cover behavioral aspects like safety, outcomes, or error cases, leaving critical gaps for an AI agent to invoke it correctly in 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%, with the parameter 'ids' documented as 'Group identifiers to delete'. The description adds no additional meaning beyond the schema, such as format examples or constraints. Baseline 3 is appropriate since the schema fully describes 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 'Delete multiple Groups' clearly states the action (delete) and resource (Groups), with 'multiple' indicating batch operation. It distinguishes from single-delete operations but doesn't explicitly differentiate from other deletion tools like deleteMaterials or deleteMeshs, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., existing groups), exclusions, or compare with single-delete operations or other deletion tools in the sibling list. The agent must infer usage from the 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?
No annotations are provided, so the description carries full burden. It states the action is deletion, implying destructive behavior, but doesn't disclose critical details like whether deletions are permanent, require specific permissions, have side effects on related resources, or provide confirmation prompts. For a destructive 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 with zero waste—'Delete multiple IKChains' is front-loaded and directly conveys the core purpose without unnecessary words. Every word 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?
For a destructive tool with no annotations and no output schema, the description is incomplete. It lacks behavioral context (e.g., irreversibility, error handling), usage guidelines, and output expectations. Given the complexity of deletion operations and minimal structured data, more detail is needed to adequately inform 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%, with the 'ids' parameter documented as 'IKChain identifiers to delete'. The description adds no additional meaning beyond this, as it doesn't specify format, constraints, or examples for the IDs. Baseline score of 3 is appropriate since 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 'Delete multiple IKChains' clearly states the action (delete) and resource (IKChains), with 'multiple' indicating batch operation. It distinguishes from sibling tools like 'deleteJoints' or 'deleteConstraints' by specifying IKChains, but doesn't explicitly differentiate from similar delete operations beyond the resource type.
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 is provided. The description doesn't mention prerequisites (e.g., needing IKChains to exist), when not to use it, or how it compares to other deletion tools like 'deleteIKChains' versus individual deletions. Usage is implied by the 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?
No annotations are provided, so the description carries full burden. 'Delete' implies a destructive mutation, but the description doesn't disclose whether deletion is permanent, requires specific permissions, affects dependent structures, or has confirmation steps. It mentions 'multiple' which hints at batch capability, but lacks behavioral details like error handling or rate limits.
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 at three words with zero waste. The description is front-loaded and efficiently communicates the core action 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 and no output schema, the description is inadequate. It doesn't explain what Joints are, the impact of deletion, return values, or error conditions. Given the complexity of a deletion operation in a 3D modeling context (inferred from sibling tools), more context is needed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the parameter 'ids' documented as 'Joint identifiers to delete'. The description adds no additional parameter semantics beyond what the schema provides. With one parameter and high schema coverage, the baseline is 4 as the description doesn't need to compensate, but it also adds no value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete multiple Joints' clearly states the action (delete) and resource (Joints), but it's vague about scope and doesn't distinguish from sibling tools like deleteIKChains or deleteGroups. It specifies 'multiple' which adds some context, but doesn't clarify what Joints are or what deletion entails.
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 deleteIKChains or deleteGroups. The description doesn't mention prerequisites, consequences, or appropriate contexts for deletion. The agent must infer usage from the 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 full burden but discloses minimal behavioral traits. It indicates a destructive operation ('Delete') but doesn't specify whether deletion is permanent/reversible, what permissions are needed, whether it affects dependent objects, or what happens on partial failure. For a destructive tool with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words with zero wasted language. It's front-loaded with the essential action and resource. Every word earns its place, making it efficient for quick scanning while conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive deletion tool with no annotations and no output schema, the description is incomplete. It doesn't address critical context like what happens to dependent geometry, whether the operation can be undone, error conditions, or confirmation requirements. The combination of destructive nature and lack of structured metadata makes this description insufficient.
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 schema description coverage is 100% with one parameter clearly documented as 'SubdivisionSurface identifiers to delete.' The description adds value by specifying 'multiple' which implies the array nature of the parameter, but doesn't provide additional semantics beyond what the schema already covers well. With zero parameters requiring extra explanation, baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete multiple SubdivisionSurfaces' clearly states the action (delete) and resource (SubdivisionSurfaces), but it's vague about scope and doesn't differentiate from sibling tools like deleteMeshes or deleteFaces. It specifies 'multiple' which adds some context, but lacks precision about what deletion entails in this 3D modeling context.
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. With many deletion tools in the sibling list (deleteMeshes, deleteFaces, deleteVertexs, etc.), the description offers no context about when SubdivisionSurface deletion is appropriate versus other deletion operations or what prerequisites might exist.
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. 'Delete' implies a destructive mutation, but it doesn't disclose behavioral traits like whether deletion is permanent, requires specific permissions, affects dependent resources, or has rate limits. The description lacks essential 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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly. No unnecessary words or structure issues.
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 destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like safety, permissions, or return values, leaving significant gaps for an AI agent to understand proper usage.
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 the parameter 'ids' documented as 'UVMap identifiers to delete'. The description adds no additional meaning beyond this, such as format examples or constraints. Baseline 3 is appropriate since the schema adequately covers 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 'Delete multiple UVMaps' clearly states the action (delete) and resource (UVMaps), with 'multiple' indicating batch operation. It distinguishes from sibling 'deleteUVMaps' vs 'deleteMaterials' etc., but doesn't explicitly differentiate from other deletion tools like 'deleteMaterials' beyond the resource name.
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. It doesn't mention prerequisites (e.g., UVMaps must exist), consequences (e.g., irreversible deletion), or when to use batch deletion versus single deletions. The description provides only the basic function without 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?
No annotations are provided, so the description carries full burden. 'Get' suggests a read operation, but it doesn't disclose behavioral traits such as whether it requires authentication, rate limits, error handling for invalid IDs, or the return format. The description adds minimal value beyond the basic action, lacking crucial context for safe invocation.
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 waste: 'Get multiple Clips by IDs'. It is front-loaded and appropriately sized, conveying the core purpose without unnecessary elaboration. Every word 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 no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't explain what a 'Clip' is, the expected return values, error conditions, or usage context. For a tool with no structured metadata, the description should provide more guidance to compensate, but it falls short.
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 the 'ids' parameter documented as 'Clip identifiers'. The description adds no additional meaning beyond this, such as ID format, constraints, or examples. With high schema coverage, the baseline is 3, as the schema does the heavy lifting without description enhancement.
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 'Get multiple Clips by IDs' clearly states the action (Get) and resource (Clips) with a specific scope (by IDs). It distinguishes from siblings like 'listClips' (which presumably lists all clips) and 'getClips' (singular) by specifying batch retrieval. However, it doesn't explicitly contrast with 'getClips' (if that exists) or other retrieval tools, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'listClips' or 'getClips' (singular). It implies usage when you have specific IDs, but doesn't state prerequisites, exclusions, or compare to siblings. This leaves the agent to infer context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states a read operation ('Get'), implying non-destructive behavior, but doesn't disclose error handling (e.g., invalid IDs), rate limits, authentication needs, or return format. For a tool with no annotations, this leaves significant behavioral gaps, though it correctly implies a safe read.
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, front-loaded sentence with zero waste: 'Get multiple Constraints by IDs'. It efficiently conveys the core action and key input, making it easy to parse. No extraneous details or redundancy are present.
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 no annotations, no output schema, and a simple input schema, the description is incomplete. It lacks details on return values (e.g., structure of constraints), error cases, or behavioral context. For a tool in a server with many siblings, more context would help the agent use it correctly, making this minimal description inadequate.
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 the parameter 'ids' documented as 'Constraint identifiers' in the schema. The description adds no additional meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline is 3, as the description doesn't compensate but doesn't detract either.
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') and resource ('Constraints'), specifying it retrieves multiple items by IDs. It distinguishes from sibling 'listConstraints' by focusing on specific IDs rather than listing all, but doesn't explicitly contrast with 'getConstraints' vs 'getMetadata' or similar. The purpose is specific and actionable.
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 'listConstraints' (for all constraints) or 'getProperty' (for property retrieval). The description implies usage when IDs are known, but lacks explicit context, prerequisites, or exclusions. It's minimal and leaves the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Get multiple Faces by IDs' but doesn't disclose behavioral traits such as read-only vs. mutative nature, error handling for invalid IDs, rate limits, or return format. This is a significant gap for a tool with no 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 a single, efficient sentence with no wasted words, making it easy to parse. It's appropriately sized and front-loaded, delivering the core purpose immediately 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 no annotations, no output schema, and a simple parameter schema, the description is incomplete. It lacks details on behavior, error handling, return values, and differentiation from siblings like 'listFaces'. For a retrieval tool in a complex 3D modeling context, this leaves significant 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?
Schema description coverage is 100%, with the parameter 'ids' documented as 'Face identifiers'. The description adds minimal value beyond the schema by implying retrieval of multiple items, but doesn't provide additional context like ID format or constraints. Baseline 3 is appropriate since 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 ('Get') and resource ('multiple Faces by IDs'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'listFaces' or 'getFaces' (if that existed), which would specify scope or filtering differences. It's specific but lacks 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?
No guidance is provided on when to use this tool versus alternatives like 'listFaces' or other 'get' tools for Faces. The description implies retrieval by IDs but doesn't specify prerequisites, context, or exclusions, leaving usage unclear relative to siblings.
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 'Get' which implies a read operation, but doesn't disclose behavioral traits like whether it's safe, idempotent, or has side effects. It also doesn't describe return format, error handling, or rate limits, leaving significant gaps for a tool with no 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 a single, efficient sentence with zero waste—'Get multiple Groups by IDs' is front-loaded and directly conveys the core functionality without unnecessary elaboration, 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 no annotations and no output schema, the description is incomplete for a tool that retrieves data. It lacks details on return values, error cases, or behavioral constraints, which are crucial for an agent to invoke it correctly. The high schema coverage helps with inputs, but overall context is insufficient.
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 the parameter 'ids' clearly documented as 'Group identifiers' in the schema. The description adds minimal value beyond this, only reinforcing that IDs are used. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't provide additional syntax or format 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 action ('Get') and resource ('multiple Groups by IDs'), making the purpose immediately understandable. It distinguishes from listGroups by specifying retrieval by IDs rather than listing all groups. However, it doesn't explicitly contrast with getGroups (singular) if that exists, though the sibling list includes only listGroups and updateGroups.
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 listGroups or getGroups (if singular). It mentions 'by IDs' which implies usage when IDs are known, but offers no explicit when/when-not instructions or named alternatives, leaving the agent to infer context from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get multiple IKChains by IDs', which implies a read-only operation, but doesn't clarify if it's safe, what happens with invalid IDs (e.g., errors, partial results), or the return format. For a tool with no annotations, this lacks critical behavioral details like error handling or output structure.
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: 'Get multiple IKChains by IDs'. It is front-loaded with the core action and resource, with no wasted words. Every part of the sentence contributes directly to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a retrieval tool with one parameter), no annotations, and no output schema, the description is incomplete. It doesn't explain what IKChains are, how results are returned (e.g., array, object), or error cases. For a tool in a 3D modeling context with many siblings, more context is needed to ensure proper use without relying on external knowledge.
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 IDs', which aligns with the single parameter 'ids' in the input schema. Since schema description coverage is 100% (the parameter 'ids' is described as 'IKChain identifiers'), the description adds minimal value beyond the schema. It doesn't provide additional context like ID format or constraints, so it meets the baseline for high schema coverage.
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 'Get multiple IKChains by IDs' clearly states the action (Get) and resource (IKChains), with the scope 'by IDs' indicating retrieval of specific items. It distinguishes from sibling tools like 'listIKChains' (which likely lists all) and 'getIKChains' (singular), though it doesn't explicitly name these alternatives. The purpose is specific but could be more precise about 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 sibling tools like 'listIKChains' (for listing all) or 'getIKChains' (if a singular version exists), nor does it specify prerequisites such as needing valid IDs. Usage is implied by the name and parameters but not explicitly stated.
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 'Get multiple Joints by IDs' but doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires specific permissions, error handling for invalid IDs, or the format of returned data. For a tool with no 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 extremely concise with a single sentence: 'Get multiple Joints by IDs'. It is front-loaded and wastes no words, making it efficient and easy to parse. Every word earns its place by conveying the core action and input.
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 retrieval tool with no annotations and no output schema), the description is incomplete. It doesn't explain what a 'Joint' is, the expected return format, error conditions, or usage context. For a tool in a server with many sibling tools, more detail is needed to ensure the agent can use it correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'ids' parameter documented as 'Joint identifiers'. The description adds no additional meaning beyond this, as it merely restates that IDs are used to get joints. With high schema coverage, the baseline score of 3 is appropriate, as the schema already provides adequate parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('multiple Joints by IDs'), making the purpose understandable. It distinguishes from sibling tools like 'listJoints' (which likely lists all joints) and 'getJoints' (which retrieves specific ones by ID). However, it doesn't specify what a 'Joint' is in this context, leaving some ambiguity about the resource type.
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. There's no mention of prerequisites, limitations, or comparison to sibling tools like 'listJoints' or 'getJoints' (if that's a different tool). The description is purely functional without contextual advice.
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 it's a 'Get' operation (implying read-only), but doesn't clarify whether it requires specific permissions, how it handles invalid IDs (e.g., errors vs. partial results), rate limits, or return format. For a tool with no 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 purpose and uses clear terminology. Every word earns its place, 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 no annotations and no output schema, the description is incomplete. It doesn't explain what 'Materials' are in this context (e.g., 3D modeling materials), the return format, error handling, or how it differs from sibling tools like listMaterials. For a tool with one parameter but complex domain context, more detail is needed to guide 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?
Schema description coverage is 100%, with the parameter 'ids' documented as 'Material identifiers' in the schema. The description adds minimal value beyond the schema by emphasizing 'multiple Materials by IDs', which reinforces the array nature but doesn't provide additional context like ID format, constraints, or examples. Baseline 3 is appropriate given 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 'Get multiple Materials by IDs' clearly states the action (Get) and resource (Materials), and specifies the scope (multiple, by IDs). It distinguishes from listMaterials (which presumably lists all materials) by focusing on retrieval by specific identifiers. However, it doesn't explicitly contrast with getProperty or other get* tools that might retrieve 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 like listMaterials (for listing all materials) or getProperty (for retrieving material properties). It doesn't mention prerequisites, error conditions, or typical use cases. The agent must infer usage from the tool name and parameter alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic operation. It doesn't disclose whether this is a read-only operation, what happens with invalid IDs (error vs partial results), response format, pagination, or rate limits. The description is minimal and lacks 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 extremely concise at just 4 words with zero wasted language. It's front-loaded with the core functionality and uses efficient phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'get' returns (full mesh data vs metadata), error conditions, or how it differs from listMeshs. The minimal description leaves too many questions unanswered for effective tool selection.
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 the single parameter 'ids' well-documented as 'Mesh identifiers' array. The description adds no additional parameter semantics beyond what the schema provides, but the schema coverage is comprehensive so baseline 3 is appropriate.
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 'Get multiple Meshs by IDs' clearly states the action (get) and resource (Meshs) with the specific mechanism (by IDs). It distinguishes from listMeshs which likely returns all meshes without filtering, but doesn't explicitly mention this sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like listMeshs or getMetadata. There's no mention of prerequisites, performance considerations, or error handling for invalid IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves views but does not mention whether this is a read-only operation, if it requires specific permissions, what the output format is, or any side effects. This leaves significant gaps in understanding how the tool behaves.
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 front-loaded and wastes no space, 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 complexity of a 3D scene tool with no annotations and no output schema, the description is insufficient. It does not explain what the returned views entail (e.g., images, data structures), how they are formatted, or any dependencies, leaving the agent with incomplete context for proper 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 input schema has 100% description coverage, so the schema already documents all parameters well. The description does not add any meaning beyond the schema, such as explaining how parameters interact or providing usage examples. 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 ('Get') and the resource ('top, front, right, and perspective views of the scene'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'getSelection' or 'getProperty', which might also retrieve scene information but in different forms.
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. With many sibling tools like 'getSelection' or 'getProperty' that also retrieve data, there is no indication of context, prerequisites, or exclusions for using 'getQuadView'.
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 'Get' but doesn't clarify if this is a read-only operation, what permissions are needed, how errors are handled (e.g., invalid IDs), or the return format. For a tool with no annotation coverage, this leaves significant behavioral gaps unaddressed.
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 front-loads the core action ('Get multiple SubdivisionSurfaces') and specifies the key input ('by IDs'), making it easy to parse and understand 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 no annotations and no output schema, the description is incomplete for a tool that likely returns data. It doesn't explain what 'Get' returns (e.g., object details, properties), error behavior, or usage context. For a retrieval tool in a complex 3D modeling environment, this leaves critical 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?
Schema description coverage is 100%, with the parameter 'ids' documented as 'SubdivisionSurface identifiers'. The description adds no additional meaning beyond this, such as ID format, constraints, or examples. With high schema coverage, the baseline score of 3 is appropriate as 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 verb ('Get') and resource ('multiple SubdivisionSurfaces by IDs'), making the purpose unambiguous. It distinguishes from sibling 'listSubdivisionSurfaces' by specifying retrieval by IDs rather than listing all. However, it doesn't explicitly mention what 'Get' entails (e.g., fetching data vs. objects), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'listSubdivisionSurfaces' or 'getMetadata'. The description implies usage when IDs are known, but lacks explicit context, prerequisites, or comparisons to sibling tools, leaving the agent to infer appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'List all Curves' implies a read operation but doesn't specify whether this requires permissions, how results are returned (format, ordering), whether it's paginated (though schema suggests it might be), or any rate limits. The description adds minimal behavioral context beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, front-loading the essential information with zero wasted words. Every word earns its place in communicating the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'Curves' are in this context, what format results are returned in, or provide any behavioral context. The minimal description leaves too many questions unanswered given the tool's complexity and lack of supporting documentation.
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 four parameters (filters, limit, offset, parentId) with descriptions. The tool description adds no additional parameter information beyond what's in the schema, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all Curves' clearly states the verb ('List') and resource ('Curves'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'getCurves' or 'listBlendShapes' that might have similar listing functionality, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like 'getCurves', 'listBlendShapes', and 'query' that might retrieve similar data, there's no indication of when this specific listing tool is appropriate versus other retrieval methods.
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. 'List all Groups' implies a read operation but doesn't specify whether it requires authentication, has rate limits, returns paginated results, or what format the output takes. This is a significant gap for a tool with 4 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?
The description is extremely concise at just three words, with zero wasted language. It's front-loaded with the essential action and resource, making it immediately understandable without any 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 tool with 4 parameters and no output schema, the description is inadequate. It doesn't explain what 'Groups' are in this context, what the output format looks like, or how the filtering/pagination parameters work together. With no annotations and no output schema, 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 schema has 100% description coverage, so all parameters are documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema, which meets the baseline expectation when schema coverage is complete.
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 'List all Groups' clearly states the verb ('List') and resource ('Groups'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'getGroups' or 'performGroupOperations', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'getGroups' or 'performGroupOperations'. There's no mention of prerequisites, typical use cases, or 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. 'Convert triangles to quads' implies a mutation operation, but it doesn't specify whether this is destructive (e.g., modifies the mesh in-place), requires specific permissions, has side effects, or provides any output format. This leaves significant gaps for an AI 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 with zero wasted words. It's front-loaded with the core purpose and appropriately sized for the tool's complexity, making it easy 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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after conversion (e.g., returns success/failure, modifies mesh in-place), potential errors, or behavioral constraints. Given the complexity implied by the parameter schema, more context is needed for the agent to use this tool effectively.
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, clearly documenting the 'items' parameter and its nested properties (meshId, facesToQuadrangulate, maxAngleDeviation). The description adds no additional parameter information beyond what's in the schema, so it meets the baseline score of 3 for high schema coverage.
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 'Convert triangles to quads' clearly states the action (convert) and the resource (triangles to quads), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'triangulate' or 'createFaces' which might handle similar mesh operations, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing a mesh with triangles), exclusions (e.g., not applicable to quads), or comparison to siblings like 'triangulate' (which does the inverse operation).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool redoes an operation, implying mutation, but doesn't disclose behavioral traits such as what happens if no undo exists, whether it's reversible, error conditions, or side effects. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and directly states the tool's function, making it easy to parse. Every word earns its place, achieving optimal 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 operation) and lack of annotations or output schema, the description is incomplete. It doesn't explain what 'redo' entails in this system, potential outcomes, or how it interacts with other tools like 'undo'. For a tool with behavioral implications, more 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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is appropriate. Baseline is 4 for zero parameters, as it avoids unnecessary details and aligns with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Redo the previously undone operation', which is clear but vague. It specifies the verb ('Redo') and resource ('previously undone operation'), but doesn't differentiate from sibling tools like 'undo' or explain what constitutes an 'operation' in this context. It's not tautological but lacks specificity about the domain or scope.
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., requiring an 'undo' operation first), exclusions, or how it relates to sibling tools like 'undo'. The context is implied but not explicit, leaving gaps for an AI agent to infer proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Set' implies a mutation operation, but the description doesn't mention whether this requires specific permissions, whether changes are destructive or reversible, what happens to existing subdivision levels, or what the typical response looks like. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence with zero wasted words. It's front-loaded with the essential information and doesn't contain any unnecessary elaboration or repetition.
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 insufficiently complete. It doesn't address behavioral aspects like side effects, permissions needed, error conditions, or what constitutes success. Given the complexity implied by setting subdivision levels on surfaces, more context about what this operation actually does would be valuable.
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%, so the schema already documents the single 'items' parameter and its nested structure. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it doesn't explain what 'subdivision levels' mean in practice, valid ranges beyond the minimum, or typical use cases for setting multiple levels at once.
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 target resource ('subdivision levels for surfaces'), making the purpose immediately understandable. However, it doesn't distinguish this tool from similar sibling tools like 'updateSubdivisionSurfaces' or 'getSubdivisionSurfaces', which would require more specific 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. With sibling tools like 'updateSubdivisionSurfaces' and 'getSubdivisionSurfaces' available, there's no indication of whether this is for bulk operations, specific use cases, or how it differs from the 'update' variant.
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. 'Split meshes into separate objects' implies a destructive/mutative operation (changing mesh structure), but it doesn't disclose whether this is reversible, what permissions are needed, how results are returned, or if there are side effects like modifying scene hierarchy. For a tool that likely alters geometry, this lack of behavioral detail 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 with zero wasted words. It's front-loaded with the core action and result, making it easy to parse quickly. Every word ('split', 'meshes', 'separate objects') 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 of a mesh-splitting operation (likely mutative with structural changes), no annotations, and no output schema, the description is insufficient. It doesn't explain what 'separate objects' means in context (e.g., new mesh entities, scene nodes), potential limitations, or error conditions. For a tool that could have significant scene impact, more completeness 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?
Schema description coverage is 100%, with clear parameter documentation in the schema itself. The description adds no additional parameter semantics beyond implying 'meshes' as input, which the schema already covers via 'items' with 'meshId'. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, though the description doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('split') and target resource ('meshes'), specifying they become 'separate objects'. It distinguishes from sibling tools like 'combineMeshes' (which does the opposite) and 'duplicate' (which copies rather than splits). However, it doesn't explicitly contrast with all potential alternatives like 'triangulate' or 'quadrangulate', keeping it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 existing meshes), scenarios where splitting is appropriate (e.g., for material assignment or export), or warnings about when not to use it (e.g., on already separated meshes). With no usage context provided, this scores low.
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. 'Convert n-gons to triangles' implies a mutation operation (changing mesh geometry), but the description doesn't state whether this is destructive to original data, requires specific permissions, has side effects, or what the output looks like. For a tool that modifies mesh structures, this lack of behavioral context 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 with zero wasted words. It's front-loaded with the core purpose and uses precise terminology ('n-gons', 'triangles'). Every word earns its place, making it easy 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 that this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'triangulate' means in practical terms (e.g., breaking polygons with >3 sides into triangles), potential impacts on mesh topology, or what happens to attributes like UVs or normals. For a tool that alters geometry, more context is needed to use it safely and effectively.
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 no parameter information beyond what's already in the schema (which has 100% coverage). The schema thoroughly documents the 'items' array with its nested properties like 'meshId', 'method', 'facesToTriangulate', and 'preserveBoundaries'. Since schema coverage is high, the baseline score of 3 is appropriate—the description doesn't compensate but doesn't need to given the comprehensive 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 'Convert n-gons to triangles' clearly states the tool's function with a specific verb ('Convert') and resource ('n-gons'), and it distinguishes itself from siblings like 'quadrangulate' which performs a different polygon conversion. However, it doesn't explicitly mention that this is a mesh processing operation, which could be inferred from context but isn't stated.
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 a mesh with n-gons), exclusions (e.g., not applicable to curves), or compare it to related tools like 'quadrangulate' for converting to quads. The agent must infer usage from the tool name and context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Update' implies mutation, but the description doesn't state whether this is destructive (overwrites existing data), requires specific permissions, has side effects on related resources, or provides confirmation of changes. For a mutation tool with complex nested parameters, this lack of behavioral context 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 function without unnecessary words. It's front-loaded with the core action ('Update multiple BlendShapes') and includes the key operational detail ('in a single operation'). Every word serves a purpose, making it maximally concise while still conveying essential 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?
Given the tool's complexity (mutation operation with deeply nested parameters), absence of annotations, and no output schema, the description is inadequate. It doesn't explain what 'update' entails (e.g., partial vs. full updates), error handling, performance implications of batch operations, or expected response format. For a tool that modifies 3D modeling data, more contextual information is needed for safe and 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?
Schema description coverage is 100%, so the schema fully documents the single 'items' parameter and its nested structure. The description adds no parameter information beyond what's in the schema—it doesn't explain what 'multiple BlendShapes' means in practice or provide examples. With complete schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('multiple BlendShapes'), making the purpose immediately understandable. It distinguishes from sibling tools like 'createBlendShapes' and 'deleteBlendShapes' by focusing on updates rather than creation or deletion. However, it doesn't specify what aspects of BlendShapes are updated (weights, deltas, etc.), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., existing BlendShapes), compare to single-update tools (none in siblings), or specify use cases like batch operations. Without any context about when or why to choose this tool, users must infer usage from the 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, the description carries full burden but only states it updates multiple curves. It doesn't disclose behavioral traits like whether this is destructive, requires specific permissions, has rate limits, returns confirmation, or handles partial failures. For a mutation tool with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero waste, front-loaded with core action. Every word earns its place by conveying batch nature and target resource 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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'update' entails (full replacement vs partial), success/failure behavior, or return values. Given the complexity of curve parameters in the schema, more context is needed for safe usage.
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 'items' parameter and its nested properties. The description adds no parameter semantics beyond implying batch updates, which is already clear from the schema structure. Baseline 3 is appropriate when schema does all the work.
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 ('multiple Curves'), specifying it's a batch operation ('in a single operation'). It distinguishes from single-update operations but doesn't explicitly differentiate from other batch tools like 'batchSetProperty' or 'batchTransform'.
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 'updateCurves' (if single), 'batchSetProperty', or 'editCurveControlPoints'. The description mentions 'multiple Curves' but doesn't specify prerequisites, constraints, or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Update' implies mutation, but there's no information about permissions required, whether updates are atomic/transactional, error handling for partial failures, or what happens to existing driver configurations not mentioned. For a batch 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?
Extremely concise - a single sentence that directly states the tool's function without any fluff. Every word earns its place: 'Update' (action), 'multiple Drivers' (resource and scope), 'in a single operation' (batch characteristic).
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 batch mutation tool with complex nested parameters (items array with multiple sub-properties), no annotations, and no output schema, the description is inadequate. It doesn't explain what Drivers are, what 'updating' entails, expected outcomes, or error conditions. The agent would struggle to use this tool correctly without significant external knowledge.
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 'items' parameter and its nested structure comprehensively. The description adds no additional parameter information beyond what's in the schema. According to guidelines, when schema coverage is high (>80%), the baseline is 3 even with no param info in description.
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 ('Drivers'), and specifies it's a batch operation ('multiple Drivers in a single operation'). However, it doesn't differentiate from sibling tools like 'updateDrivers' vs 'updateChannels' or 'updateMaterials' - all have similar 'updateX' patterns without explaining what distinguishes Drivers from other entities.
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. There's no mention of prerequisites, when batch updating is preferable to individual updates, or how this relates to sibling tools like 'createDrivers' or 'getDrivers'. The description provides only the basic function without 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 provided, the description carries full burden but offers minimal behavioral insight. It states it's an update operation (implying mutation) but doesn't disclose permission requirements, whether changes are atomic/transactional, error handling for partial failures, or what the response contains. For a batch mutation tool with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with zero wasted words. Front-loads the core action ('Update multiple Groups') and adds only essential qualifying information ('in a single operation'). Every word 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?
For a batch mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what constitutes a successful update, return format, error conditions, or how it differs from similar batch operations. The high schema coverage helps with parameters, but overall context is lacking.
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 single 'items' parameter and its nested structure. The description adds no parameter-specific information beyond implying batch capability. Baseline 3 is appropriate when schema does all parameter documentation.
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 ('multiple Groups'), specifying it's a batch operation ('in a single operation'). It distinguishes from single-update tools but doesn't explicitly differentiate from sibling 'performGroupOperations' which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'performGroupOperations' or individual update tools. The description mentions it updates multiple groups, but doesn't specify prerequisites, limitations, or appropriate contexts for batch operations versus other approaches.
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 provides minimal behavioral insight. It implies a write operation ('Update') but doesn't disclose permissions needed, whether changes are reversible, error handling for invalid IDs, or if it's atomic (all-or-nothing). This is inadequate for a mutation tool with complex 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?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and scope, making it easy 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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits (e.g., side effects, idempotency), usage context, and expected outcomes, leaving significant gaps for an agent to operate safely and effectively.
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 well-documented in the schema. The description adds no additional meaning beyond implying batch processing via 'multiple IKChains' and 'single operation', which aligns with the 'items' array parameter but doesn't elaborate further.
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 ('multiple IKChains'), specifying it's a batch operation ('in a single operation'). It distinguishes from single-update tools but doesn't explicitly differentiate from other batch tools like 'batchSetProperty' or 'updateGroups'.
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., existing IKChains), compare to 'updateIKChains' (if single-update exists) or other batch tools, or specify scenarios like bulk edits versus individual updates.
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's an update operation. It lacks critical behavioral details: whether it's idempotent, requires specific permissions, has side effects (e.g., affecting child objects), error handling for invalid IDs, or mutation scope (partial vs. full updates). This is inadequate for a mutation tool with complex 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?
The description is a single, efficient sentence with zero waste—it directly states the tool's core function. It's appropriately sized and front-loaded, making it easy 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?
For a mutation tool with no annotations, no output schema, and complex nested parameters, the description is insufficient. It doesn't explain what 'update' entails (e.g., overwriting vs. merging), return values, error conditions, or interaction with sibling tools like 'createJoints' or 'deleteJoints'. More context is needed for safe and 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?
Schema description coverage is 100%, so the schema fully documents the 'items' parameter and its nested properties. The description adds no parameter semantics beyond implying batch updates, which is already clear from the schema's array structure. Baseline 3 is appropriate as 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 ('Update') and resource ('multiple Joints'), specifying it's a batch operation ('in a single operation'). This distinguishes it from single-update tools, though it doesn't explicitly differentiate from sibling tools like 'updateJoints' (if it exists) or other batch tools like 'batchSetProperty'.
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 existing Joints), exclusions (e.g., not for creating Joints), or compare to siblings like 'updateJoints' (if single-update) or 'batchSetProperty' (for generic property updates).
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 it's an update operation, implying mutation, but doesn't disclose behavioral traits like whether it requires specific permissions, if changes are reversible, what happens to unspecified fields (partial vs full updates), error handling for invalid IDs, or rate limits. The batch nature is mentioned, but without details on transactionality or ordering.
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 ('Update multiple Materials') and adds value by specifying it's a batch operation ('in a single operation'). There is zero waste or redundancy, making it appropriately sized for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (batch update tool with 1 parameter but rich nested schema), no annotations, and no output schema, the description is inadequate. It doesn't explain return values, error conditions, or behavioral context needed for safe invocation. For a mutation tool with significant nested parameters, more completeness is required to guide the agent effectively.
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 detailed descriptions for all nested parameters (e.g., 'alphaCutoff', 'baseColor'). The description adds no parameter-specific information beyond the schema, not even clarifying that 'items' contains the update payloads. However, with high schema coverage, the baseline is 3 as 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 verb ('Update') and resource ('Materials'), and specifies it's a batch operation ('multiple Materials in a single operation'). However, it doesn't explicitly differentiate from sibling tools like 'updateMaterials' vs 'createMaterials' or 'deleteMaterials', which would require mentioning it modifies existing materials rather than creating new ones or deleting 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., materials must exist), exclusions (e.g., cannot create materials), or compare to siblings like 'updateMaterials' vs 'batchSetProperty' or 'assignMaterials'. The context of batch updating is implied but not explicitly stated as a usage scenario.
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 it's an update operation (implying mutation) but doesn't disclose critical behavioral traits: whether it requires specific permissions, if changes are reversible, error handling for invalid IDs, or performance implications of batch updates. For a mutation tool with zero annotation coverage, this is a significant gap in safety and 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 a single, efficient sentence with zero waste: 'Update multiple Meshs in a single operation.' It's front-loaded with the core action and scope, making it easy to parse. Every word earns its place by clarifying it's a batch update.
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 (batch mutation with many configurable properties), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what happens on success/failure, return values, or constraints like ID validity. For a mutation tool in a rich sibling environment, more context is needed to guide safe and 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?
Schema description coverage is 100%, so the schema fully documents the single parameter ('items' array with detailed sub-properties). The description adds no meaning beyond the schema, merely restating that it updates multiple meshes. Baseline 3 is appropriate when the schema does all the heavy lifting, but no extra value is added.
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 ('multiple Meshs'), specifying it's a batch operation ('in a single operation'). It distinguishes from single-update tools but doesn't explicitly differentiate from other batch tools like batchSetProperty or batchTransform, which could also affect meshes. The purpose is clear but sibling differentiation is incomplete.
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 is provided. The description doesn't mention prerequisites (e.g., existing meshes), compare to single-update methods, or specify use cases like bulk editing. With many sibling tools (e.g., batchSetProperty, transformVertices), the lack of context leaves the agent guessing about appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Update' implies a mutation operation, the description lacks critical details: it doesn't specify whether this requires special permissions, if updates are atomic or partial, what happens on failure (e.g., if some items succeed and others fail), or any rate limits. For a batch 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 front-loads the core action ('Update multiple SubdivisionSurfaces') and adds a useful operational detail ('in a single operation'). There is zero wasted language, and it immediately communicates the tool's scope 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 complexity of a batch mutation tool with no annotations and no output schema, the description is insufficient. It lacks behavioral context (e.g., error handling, idempotency), does not explain what 'update' entails for SubdivisionSurfaces, and provides no guidance on usage relative to siblings. The 100% schema coverage helps with parameters, but overall completeness is poor for this type of operation.
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 single parameter ('items') and its nested structure. The description adds no parameter-specific information beyond implying batch processing through 'multiple SubdivisionSurfaces' and 'single operation', which is already evident from the schema's array type. This meets the baseline of 3 where 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 verb ('Update') and resource ('multiple SubdivisionSurfaces'), making the purpose immediately understandable. It distinguishes this as a batch operation ('in a single operation'), which differentiates it from potential single-update tools. However, it doesn't explicitly contrast with sibling tools like 'updateSubdivisionSurfaces' (singular) or 'setSubdivisionLevels' that might handle similar resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'updateSubdivisionSurfaces' (singular implied), 'setSubdivisionLevels', and various other update operations, there's no indication of prerequisites, appropriate contexts, or trade-offs between batch and individual updates. The agent must infer usage solely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't specify error handling (e.g., for invalid IDs), performance traits (e.g., batch limits), or return format. This leaves gaps in understanding how the tool behaves beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter and no output schema, the description is adequate but incomplete. It covers the basic purpose but lacks details on usage context, behavioral traits, and return values, which are important given the absence of annotations and output schema. This results in a minimal viable description with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the 'ids' parameter clearly documented as 'BlendShape identifiers' in an array. The description adds minimal value beyond this, as it only reiterates that IDs are used without providing additional context like ID format or examples. This meets the baseline for high schema coverage.
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') and resource ('multiple BlendShapes by IDs'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'listBlendShapes' or 'getProperty', which could retrieve similar data through different mechanisms, leaving room for ambiguity in tool selection.
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 such as 'listBlendShapes' (which might retrieve all BlendShapes without IDs) or other 'get' tools. The description lacks context about prerequisites, like needing specific IDs, or exclusions, such as invalid IDs handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves channels but doesn't describe what 'Channels' are in this context, the return format, error handling, or any limitations (e.g., rate limits, permissions required). 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 directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (retrieval by IDs), no annotations, and no output schema, the description is minimally adequate but incomplete. It specifies what the tool does but lacks details on behavior, output, or usage context, which are needed for full understanding.
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, with the 'ids' parameter clearly documented as 'Channel identifiers' of type array. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage.
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') and resource ('multiple Channels by IDs'), making the purpose immediately understandable. It distinguishes from sibling tools like 'listChannels' (which likely lists all channels) by specifying retrieval by specific IDs, 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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention sibling tools like 'listChannels' for bulk listing or 'getProperty' for single property retrieval, nor does it specify prerequisites or appropriate contexts for use.
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 'Get multiple Drivers by IDs', which implies a read-only operation, but doesn't clarify if it's safe (e.g., non-destructive), what permissions are required, how it handles invalid IDs (e.g., errors or omissions), or the return format. For a tool with no annotations, 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: 'Get multiple Drivers by IDs'. It is front-loaded with the core action and resource, with zero wasted words. Every part of the sentence contributes directly to understanding the tool's purpose, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks behavioral details (e.g., error handling, return format) and usage guidelines. With no output schema, the agent is left guessing about the response structure, making this incomplete 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 input schema has 100% description coverage, with the 'ids' parameter documented as 'Driver identifiers' of type array of strings. The description adds minimal value beyond this, as it only reiterates 'by IDs' without explaining format, constraints, or examples. With high schema coverage, the baseline score of 3 is appropriate, as the schema does most of the work.
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 'Get multiple Drivers by IDs' clearly states the action (Get) and resource (Drivers), with specificity about retrieving multiple items via IDs. It distinguishes from sibling tools like 'listDrivers' (which likely lists all) and 'getDrivers' (singular retrieval), though it doesn't explicitly name these alternatives. The purpose is unambiguous but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description implies usage when you have specific Driver IDs, but it doesn't mention when to choose this over 'listDrivers' (for all drivers) or 'getDrivers' (for a single driver), nor does it discuss prerequisites or exclusions. This leaves the agent with minimal context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get' implies a read-only operation, but it doesn't specify whether this requires authentication, rate limits, what happens with invalid IDs (e.g., errors, skipping), or the return format (e.g., array of objects). For a retrieval 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: 'Get multiple Layers by IDs'. It's front-loaded with the core action and resource, with zero wasted words. Every part of the sentence earns its place by specifying the verb, resource, and key input method.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no nested objects) and 100% schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it lacks details on behavioral traits (e.g., error handling) and return values. For a retrieval tool, this leaves gaps in understanding how to interpret results or handle edge cases.
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 the 'ids' parameter documented as 'Layer identifiers' in the schema. The description adds no additional meaning beyond this, such as format examples (e.g., UUIDs), constraints (e.g., max array size), or relationship to other tools. With high schema coverage, the baseline is 3 even without extra param info in the description.
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 'Get multiple Layers by IDs' clearly states the verb ('Get') and resource ('Layers'), specifying it retrieves multiple items using identifiers. It distinguishes from siblings like 'listLayers' (which likely lists all layers) and 'createLayers'/'deleteLayers' (which modify layers), but doesn't explicitly differentiate from 'getLayers' vs 'getChildren' or other 'get' tools. This is clear but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use 'getLayers' instead of 'listLayers' (e.g., for specific IDs vs all layers) or other retrieval tools like 'getChildren'. There's no context about prerequisites, error handling, or performance considerations, leaving usage entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'automatic unwrapping' but doesn't explain what this entails—e.g., whether it modifies existing UVs or creates new ones, if it requires specific mesh properties, potential side effects like overwriting data, or performance considerations. For a tool with no 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: 'Generate UV coordinates using automatic unwrapping.' It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a tool with a well-documented schema. Every part of the sentence earns its place by clarifying the action and method.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a UV generation tool with nested parameters), no annotations, and no output schema, the description is minimally adequate. It states the purpose clearly but lacks behavioral details, usage context, and output information. The schema covers parameters well, but the description doesn't compensate for missing annotations or output schema, making it incomplete for safe and 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 input schema has 100% description coverage, with detailed docs for all parameters (e.g., 'method' with enum values, 'margin' with range). The description adds no parameter-specific information beyond the schema, not even high-level context like what 'items' represent. With high schema coverage, the baseline is 3, as 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 tool's purpose: 'Generate UV coordinates using automatic unwrapping.' It specifies the action ('generate UV coordinates') and method ('automatic unwrapping'), which is more informative than just restating the name. However, it doesn't explicitly differentiate from sibling tools like 'createUVMaps' or 'transformUVs', which might have overlapping or related functionality in UV mapping.
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 mesh), exclusions (e.g., not suitable for manual UV editing), or refer to sibling tools like 'createUVMaps' for initial UV creation or 'transformUVs' for modifying existing UVs. This leaves the agent without context for tool selection.
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:

[![3d-mcp MCP server](https://glama.ai/mcp/servers/team-plask/3d-mcp/badges/card.svg)](https://glama.ai/mcp/servers/team-plask/3d-mcp)

Score Badge

Copy to your README.md:

[![3d-mcp MCP server](https://glama.ai/mcp/servers/team-plask/3d-mcp/badges/score.svg)](https://glama.ai/mcp/servers/team-plask/3d-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/team-plask/3d-mcp'

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