3D Visualizer
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation3/5
Several tools occupy near-adjacent roles: set_3d_camera vs navigate_3d_view for camera control, capture_3d_view vs preview_3d_views for image inspection, and manage_3d_views vs manage_3d_scene_states for saved state. The long descriptions help, but an agent must carefully compare multiple tools before selection. The app-only transport tools (submit_viewer_reply, read_viewer_data) also blur the boundary between domain actions and internal communication.
Naming Consistency4/5The naming is generally very consistent: snake_case verb-first names such as open_3d_files, set_3d_camera, and manage_3d_scene_states create a clear pattern. Minor divergences like open_depth_image, visualize_points, submit_viewer_reply, and read_viewer_data do not use the same 3d marker, but the overall verb_noun convention remains predictable.
Tool Count2/5With 27 tools, the surface is too large; only a handful of related verbs are needed for the core workflows. Many tools could be grouped or filtered into a smaller, more focused set. The breadth may be useful, but the agent-facing tool count creates too much decision overhead.
Completeness4/5The domain is broadly covered: opening local, remote, and depth data; inspecting, updating, closing, transforming, aligning, measuring, selecting, exporting, comparing, and animating scenes. Minor gaps include lack of explicit per-object deletion and a couple of internal app-only transport tools that do not fit the domain surface.
Average 4/5 across 27 of 27 tools scored. Lowest: 1.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 5 of 5 community issues answered or closed in the last 6 months
- 243 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds little beyond that—'app-only transport' is ambiguous about what the tool actually does with the data. There is no disclosure about return size, pagination behavior (despite the offset parameter), or any restrictions on use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (a single fragment), which might read as concise, but it is under-specified rather than efficiently informative. It lacks any structure or prioritization of key information. Conciseness is only valuable when the essential details are present, which they are not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (as indicated by context signals), the description does not leverage it or explain return values. With 4 parameters and a non-trivial purpose, the description is grossly incomplete. An agent cannot safely or correctly invoke this tool without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides zero explanation of the parameters. Terms like 'resource', 'scene_id', 'offset', and 'renderer_id' are left entirely undefined. The description does nothing to help an agent understand what values are valid or what effect each parameter has.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic and does not clearly state what the tool does. It lists possible contents ('session metadata, pending commands or bounded geometry chunks') but does not use a clear verb like 'reads' or 'retrieves'. It fails to differentiate from sibling tools like inspect_3d_scene or list_3d_scenes, which likely also involve reading scene data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 phrase 'app-only transport' hints at an internal purpose but is not elaborated, and no conditions or exclusions are mentioned. An agent has no idea when this is the appropriate tool to call.
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?
Annotations provide only readOnlyHint=false, which indicates this is not a read-only operation, and destructiveHint=false. However, the description does not clarify the side effects of this operation beyond 'acknowledge'. It does not state whether it commits state, sends data, or is a simple acknowledgment, nor does it mention any required permissions or side effects. The description is too terse to disclose behavioral traits, but it does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, only 10 words, and front-loads the verb 'acknowledge'. However, this conciseness comes at the cost of clarity and completeness. The structure is efficient in terms of length, but it sacrifices necessary detail, making it under-specified rather than effectively concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 2 required parameters, an output schema, and nested objects, indicating moderate complexity. The description does not explain the output schema's role, nor does it provide enough context about when to use this tool given 26 sibling tools in the 3D viewer domain. The lack of usage guidance and parameter semantics leaves the agent inadequately informed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no descriptions for the parameters. The description mentions 'acknowledge a rendered command result' but does not explain the meaning of 'scene_id' or 'reply'. It fails to clarify that 'reply' might contain a command response or specific fields, and 'scene_id' likely references a scene context. Since there are nested objects and no schema descriptions, the description must compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'App-only transport: acknowledge a rendered command result' uses specific verb 'acknowledge' and resource 'rendered command result', but it is vague about what action the tool performs. It does not clearly state that it submits a viewer reply to complete a command, and it does not differentiate itself from siblings like read_viewer_data or manage_3d_views. The phrase 'App-only transport' is technical jargon that may confuse agents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 that it is for providing a reply to a rendered command result, nor does it indicate that it might be used after a command has been executed. There is no discussion of alternatives or exclusions, leaving the agent to guess the use case.
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?
There is a direct contradiction with annotations. The description says 'Omitted overlays/vectors are removed' and 'Replace the existing scene's geometry', which are destructive actions, yet annotations declare destructiveHint=false. This is a serious inconsistency that can mislead an agent into believing the tool is non-destructive. The description also does not disclose other behavioral aspects like side effects on scene state, making it unreliable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no superfluous wording. It front-loads the core action in the first sentence and adds viewer context in the second. 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description fails to adequately cover the tool's behavior. The contradiction with annotations undermines trust, and parameter semantics are only partially explained. For a tool with 6 parameters and a clear destructive action, the description is not complete enough for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 0%, the description must explain parameter semantics. It implicitly identifies points as geometry and vectors as overlays, and scene_id as the target scene. However, it does not explain colors, target, or vector_scale. With 6 parameters and no schema descriptions, this partial coverage is insufficient for an agent to correctly construct calls for all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Replace') and resource ('the existing scene's geometry') and clarifies what is preserved ('camera') and what happens to omitted overlays/vectors ('removed'). It distinguishes from siblings like transform_3d_object or set_3d_object by focusing on geometry replacement. However, it does not explicitly name a sibling to differentiate from, so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context: it mentions reusing the active inline viewer or browser fallback, which implies when this tool can be used. It does not explicitly state when NOT to use it or point to alternatives. Given the many sibling tools, clearer routing would be helpful, but the purpose and scope are clear enough for an agent to infer typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to restate safety. It adds behavioral details: it outputs a multi-view PNG, includes an enabled grid, legend, and selection summary, and preserves the original camera. However, it doesn't disclose how the single PNG is formatted (e.g., which views are combined) or whether it affects the viewer state beyond the camera, though the readOnly hint covers that. The added details are useful but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core function ('Return one labeled multi-view PNG') and then adding key constraints ('preserving the original camera', 'Disable split comparison first'). The additional features (enabled grid, legend, selection summary) are concise and relevant. Only minor waste: the grid/legend details could be considered extraneous, but they add context for what the PNG includes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only 2 parameters, 1 required, no output schema, and annotations cover its read-only nature. The description tells the agent what the tool does, prerequisites, and what the output will contain (labeled multi-view PNG with grid/legend/selection summary). It doesn't specify the exact PNG layout or how the presets map to views, but the schema enum provides that. The only missing piece is explicit routing guidance, but for the tool's complexity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must compensate for parameter semantics. The description does not mention 'presets' or 'scene_id' at all. However, the schema has clear defaults for 'presets' (['front', 'top', 'isometric']) and the enum list is self-explanatory. 'scene_id' is standard across siblings. Since coverage is 0%, description should have clarified, but the schema is simple and the tool's purpose implies the presets are views to include. This is a partial gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: to return a labeled multi-view PNG to choose a useful angle, while preserving the original camera. This distinguishes it from siblings like 'capture_3d_view' which likely captures a single view, and from 'navigate_3d_view' which changes the camera. The inclusion of 'multi-view PNG' is specific enough to differentiate it from a simple capture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear instruction to 'Disable split comparison first' as a prerequisite, but does not explicitly state when to use this tool versus alternatives like 'capture_3d_view' or 'navigate_3d_view'. The context is implied by the tool's purpose (choosing an angle) but no alternative is mentioned. This is a gap in routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive, and the description adds meaningful behavioral detail: it returns an actual PNG, caps resolution at 1024 pixels per side, and requires a viewer or fallback. This goes beyond the structured hints without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the core output type and size, then state the prerequisite. Every clause adds useful information, and there is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read-only tool, the description adequately covers the output format, size constraint, and necessary viewer prerequisite. It does not explain scene_id, but the low complexity and read-only annotations keep the missing guidance from being a serious gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, scene_id, with 0% schema description coverage, and the tool description never explains what scene_id represents, what formats are expected, or how it relates to the rendered canvas. The parameter name and schema title are self-evident at a basic level, but the description does not compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific action—returning a PNG of the rendered 3D canvas—and includes the output format and size limit. It also states the intended purpose ('so the agent can visually inspect the result'), which helps distinguish it from tools that manipulate or load scenes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear prerequisite (active inline viewer or explicit browser fallback) and implies this is for visual inspection of rendered output. However, it does not explicitly say when to use this tool versus sibling tools like preview_3d_views, and it offers no exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it is not read-only and not destructive, but the description adds valuable context: it releases a local server and temporary data, disconnects active viewers, and explicitly states it does not delete source files. This goes beyond the annotations and clarifies side effects without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each carrying meaningful information. The main action is front-loaded, and the clarification about not deleting source files is a useful safeguard. There is no redundant or unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single obvious parameter and an output schema, the description covers the key behavioral aspects (releases server/temp data, disconnects viewers, preserves source files). It does not address edge cases like idempotency or invalid scene IDs, but given the simplicity, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name 'scene_id' with a title, and schema_description_coverage is 0%. The description does not mention or explain the scene_id parameter at all, leaving the agent to infer its meaning from context. With low coverage, the description was expected to compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Release' and names the resource 'viewer's local server and temporary data', clearly distinguishing this from other sibling tools like open_3d_files or update_3d_scene. It also explicitly clarifies it does not delete user source files, further differentiating it from destructive operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is used to close or disconnect a viewer session, but it does not explicitly state when to use it versus alternatives or mention any exclusions. Given it is the only 'close' tool among siblings, the usage is largely inferred but not directly guided.
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?
The annotations declare destructiveHint=false, indicating the tool is not destructive, yet the description explicitly mentions 'delete' as an action and states that empty set results 'clear the active selection.' These are destructive or state-changing operations that contradict the annotation. The description also reveals that geometry updates expire selections, which is a non-trivial behavior not captured by annotations. However, because the description directly contradicts an annotation, this dimension receives a score of 1 and the annotation_contradiction flag is set to true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but each sentence serves a purpose. It front-loads the core functionality in the first sentence, then covers toggling, combining, defaults, edge cases, and persistence in subsequent sentences. There is no fluff or repetition, and the structure is logical: starting with the primary use case, then parameters, then caveats. The length is appropriate for the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, multiple actions, and an output schema, the description provides comprehensive context. It explains default behaviors (isolate=false, focus=false), edge cases (empty set results), and lifecycle (expiration on geometry updates, persistence via scene-state export). It even hints at interactions with other tools. Given that an output schema exists, the description does not need to elaborate on return values. The description leaves no critical operational detail unexplained, making it complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the sole source of parameter meaning. It explains the semantics of `name`, `other` (for boolean operations), `visible` (toggle visibility), `focus` (activate/focus), `isolate` (default false preserves visibility), and `action` (enumerated operations like union, intersection, subtract). It does not explicitly address the `detail` parameter (summary vs. full) or `scene_id`, but these are either standard or inferable. The description adds significant meaning beyond the schema, covering most of the 8 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: managing named selections in a 3D scene, including saving, listing, toggling visibility, activating, and performing boolean operations. It identifies the resource (selections) and the actions, and it differentiates from siblings like export_3d_selection and manage_3d_scene_states by focusing on in-session subset management. The opening sentence 'Name the active selection; retain up to 20 independent subsets' is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides behavioral context that implies usage, such as 'Empty set results return status=empty, clear the active selection, and cannot export the previous result' and 'Geometry updates expire selections; scene-state export persists them.' This tells the agent that selections are ephemeral across geometry updates and that persistence requires scene-state export, indirectly guiding when to use this tool vs. an alternative. However, it does not explicitly name an alternative tool or state 'use this for X, not Y,' leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no hints (readOnly=false, openWorld=false, destructive=false), so the description must carry the burden. It discloses that coordinates are not normalized and that data beyond 20,000 points should use files, implying the tool cannot handle larger data. However, it does not explain side effects like opening a browser (though open_browser param exists) or exact behavior on exceeding limits. The normalization caveat adds useful context, but behavior transparency is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. The main functionality is front-loaded, and the guidance about larger data and normalization is provided clearly. Every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters and only 1 required, the description covers the core parameters (points, colors, target, vectors) but omits open_browser and vector_scale. It also does not explain the output or potential viewer interactions. While an output schema exists, it does not cover behavioral outcomes. The description is adequate for basic use but incomplete for advanced use, falling short of full guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It clarifies that 'RGB' values are integers 0..255, which adds semantics beyond the plain number type. It also interprets 'target' and 'vectors' as overlay and anchored vector arrows. However, it does not explain 'open_browser' or 'vector_scale', and does not explicitly map all parameters to their roles. The description adds some value but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: visualize up to 20,000 XYZ points with optional RGB colors, target overlay, or vector arrows. This is specific and distinct from siblings like open_3d_files or set_3d_object, which serve different functions. The mention of specific visualization options (target overlay, anchored vectors) further differentiates it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when NOT to use it: 'Use files for larger data' indicates a limit and alternative for larger datasets. It also warns that coordinates are not automatically normalized, which is a caution for usage. However, it does not name specific alternative tools or explicitly state when to use this over other visualization tools, though the limit guidance implies that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses several behavioral traits beyond annotations: EDL is off in split mode, distance colors are based on world-space distance to the right, unmatched points are NaN, paired mode requires equal counts, the one-million point limit, and that changes mark distances stale. It also notes that restored distance fields require explicit computation. Annotations are minimal (readOnlyHint=false, destructiveHint=false), so the description carries the burden and does so well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured, front-loading the primary purpose and then explaining distance behavior, limits, and recompute semantics. Every sentence adds information, though the density makes it slightly harder to parse. It is appropriately sized for a tool with 7 parameters and complex behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, 3 enums, output schema present), the description covers the key behaviors: split-mode camera linking, distance computation semantics, point limits, staleness, and recompute. It does not explain the output schema's return values, but the presence of an output schema reduces that burden. Minor gaps include not explaining 'detail' or 'status' action behavior, but the overall context is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the 7 parameters. It explains the meaning of max_distance ('nearest within max_distance'), method ('paired uses corresponding decoded order and requires equal counts'), action ('recompute,left=<source> reuses recorded settings'), and left/right ('Distance colors left by world-space distance to right'). It does not explicitly explain scene_id or detail, but the schema's enum names and defaults provide some context. Overall, the description adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Enable linked side-by-side WebGL views with the same camera') and resource ('3D clouds'), and distinguishes the tool from siblings like align_3d_clouds by explicitly saying 'No alignment is run.' It is clear about the core purpose, though it does not name a specific sibling tool for comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool (enabling/disabling linked views, computing distances, recomputing distances) and provides an explicit alternative for recompute ('recompute,left=<source> reuses recorded settings'). It does not explicitly say when not to use it versus a specific sibling, but the action enum and behavior descriptions imply the usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only readOnlyHint=false and destructiveHint=false, which add minimal safety infochen. The description adds significant behavioral context: file format support (GLB/GLTF/FBX/DAE vs 3DS static), 'stop restores camera', 'play needs two keyframes', and return of reusable keyframe poses. This goes beyond the sparse annotations and gives the agent necessary expectations about state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact but information-dense paragraph. It front-loads the core purpose and then succinctly covers modes and constraints. No extraneous fluff; every sentence contributes. It could be slightly improved with bullet points for readability, but given the density, it remains concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, 8 actions, two modes), the description is remarkably complete. It covers both modes, the actions, constraints, and file format caveats. The existence of an output schema (not shown) may cover return values, so not describing them is acceptable. The only gap is not explicitly stating error conditions or prerequisites, but this is minor compared to overall richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It does this well by explaining the role of key parameters: 'index/speed', 'goto(time in seconds, pauses)', 'dwell', 'duration', 'enabled', and clarifies that 'object_index' toggles mode. While it doesn't explain every parameter in detail (e.g., 'detail', 'scene_id'), it covers the most critical ones, making it highly valuable for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states two main modes: controlling camera keyframes or model animation, with specific actions and a distinction based on the presence of object_index. It uses a specific verb ('control') and names the resource (3D video/keyframes/animation). While it doesn't differentiate from all 27 sibling tools, it is clear within its context of 3D scene manipulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage conditions: 'With no object_index, manage camera keyframes' and implies when to use object_index for model animation. It also lists specific required actions like 'play needs two keyframes' and 'Loop requires enabled'. However, it does not explicitly say when to use this tool over siblings like 'set_3d_camera' or 'manage_3d_views', so it misses a clear 'when not to use' clause.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, which the description aligns with. It adds valuable behavioral details beyond annotations: it times out if no renderer responds, detects old widgets via renderer_matches_bundle, and compares rendered_revision with the submitted revision. These are not captured in annotations, enhancing transparency. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but densely informative. It front-loads the core purpose ('Inspect loaded geometry and build IDs'), then enumerates the data it reads, and ends with behavioral notes (timeout, revision comparison). Every sentence contributes to understanding the tool, though it could be slightly more compact. It is well-structured and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex and reads many scene properties, but it has an output schema that likely details return structure. The description covers the main input (scene_id), behavior (timeout, fallback, revision comparison), and the range of data inspected, which is sufficient for an agent to invoke it correctly. It doesn't explain error cases or the meaning of summary vs full, but the output schema and enumeration reduce the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only two parameters, but the description provides no explanation of their semantics. It doesn't clarify what 'detail' levels (summary vs full) imply or what 'scene_id' refers to beyond a scene identifier. With schema description coverage at 0%, the description should compensate, but it doesn't, leaving the agent to infer parameter roles. The only hint is the reference to the active viewer/browser fallback, which is vague.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'inspect' and the resource (loaded geometry and build IDs). It enumerates specific properties it reads (coordinates, camera, transforms, etc.), which distinguishes it from sibling tools like list_3d_scenes or capture_3d_view. The mention of 'renderer_matches_bundle' further clarifies a unique behavior, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it's for reading scene state (geometry, camera, viewport, etc.) from the active inline viewer or browser fallback. It notes timeout behavior and revision comparison as caveats. However, it does not explicitly state when NOT to use it or name alternative tools, so it lacks explicit exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description importantly reveals stateful behavior: path_point appends to an active path, undo removes its last point, and close_path toggles closure. This is genuinely useful context that the schema and annotations do not provide. The clear action is described, and there is no contradiction with the declared 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences earn their place: the first states the overall purpose, and the second compresses the action semantics with no wasted words. The most important differentiators (stateful path actions) are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the tool is a measurement helper, the description covers the action variants and the stateful behavior needed to call it correctly. It lacks explicit guidance on the detail parameter and on interplay with other measurement tools, but the essential invocation semantics are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It gives meaningful semantics to action values (distance uses start/end XYZ, path_point appends end, undo removes last point) and clarifies start/end are 3D coordinates. However, the detail parameter and the scope of scene_id are left undocumented, so compensation is only partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb set ('Add/list/clear') and a clear resource ('visible measurements in scene units'), immediately distinguishing measure_3d_scene from viewer or navigation siblings like capture_3d_view and navigate_3d_view. The action list maps directly onto the enum, leaving no doubt what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys that the tool is for measurements and explains the core actions, but it never states when to prefer this tool over alternatives or when not to use it. It implies usage context via 'measurements in scene units' but does not mention any sibling tools or exclusions, so an agent gets only implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral scope: only scenes owned by this MCP process are listed, and the result includes local viewer URLs. No destructive or side-effect behavior needs 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence states the action, the object, the ownership restriction, and the output content. No filler, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only list with an output schema, the description gives the essential context: which scenes are listed (owned by this MCP process) and what they contain (local viewer URLs). Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage, so the description need not add param semantics. It clearly conveys the scope in prose instead. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), names the resource ('scenes'), and adds a clear scope ('owned by this MCP process') plus what is returned ('local viewer URLs'). This distinguishes it from the many scene-related siblings like open_3d_files, inspect_3d_scene, and set_3d_camera.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as open_3d_files, inspect_3d_scene, or manage_3d_scene_states. The scope is implied by 'owned by this MCP process,' but there is no explicit when/why or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description richly discloses behavioral details: presets use Y-up OpenGL, orbit angles are in degrees, pan/pivot use world XYZ, zoom factor below 1 moves closer, pick uses normalized canvas coordinates with top-left origin, and origin resets the pivot to 0,0,0. Since annotations provide no behavioral safety hints, this description carries the full burden and does so thoroughly, with no contradiction to 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five short, dense sentences with no filler. Each sentence delivers non-obvious information: coordinate systems, units, zoom direction, pick behavior, and pivot reset. It is front-loaded with the core purpose and efficiently packs a large amount of actionable detail into a compact space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—9 parameters, 8 action enum values, and rich coordinate-system nuances—the description covers nearly all invocation-relevant behavior, and an output schema exists so return values need not be explained. Missing pieces include the meaning of the 'detail' parameter and any explicit statement about scene prerequisites or how this differs from set_3d_camera. It is close to complete but not fully exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does for most parameters: orbit angles map to yaw/pitch, world XYZ maps to vector, zoom factor maps to factor, normalized canvas XY maps to screen, and origin/pivot semantics are explained. The scene_id is self-evident, but the 'detail' parameter is left unexplained. Overall, it adds substantial meaning beyond the raw schema despite one notable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: navigating a 3D view programmatically, with a list of specific actions like fit, orbit, pan, zoom, pick, and pivot. It goes well beyond a tautology and gives concrete operation semantics. It does not explicitly differentiate itself from sibling tools such as set_3d_camera or manage_3d_views, but the action-oriented language makes the core purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
'Navigate without UI' implies the tool is for programmatic navigation rather than interactive UI-driven navigation, which gives some usage context. However, it does not explicitly state when to prefer this tool over siblings like set_3d_camera or manage_3d_views, nor does it mention exclusions or prerequisites such as an already-open scene. The usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false (readOnlyHint=false, openWorldHint=false, destructiveHint=false), so the description carries the burden. It discloses that the tool returns a persistent scene_id and URL, appends to existing scenes, requires explicit supporting files (no implicit reads), and advises inspection to verify loading. This provides meaningful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. The primary action is front-loaded ('Open local point clouds/meshes/splats/animated models together'), and every sentence adds a necessary constraint or behavior (scene_id usage, supporting files, root restriction, return value).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers key elements: file types, append behavior, supporting-file requirement, root restriction, and return value (with output schema handling the return format). However, it fails to explain the 'open_browser' parameter, which is a notable gap. It also doesn't address error scenarios or limits beyond the root constraint, making it incomplete for a tool with multiple optional behaviors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains scene_id ('to append while preserving camera and existing objects') and implicitly defines paths via the supported file types. However, it completely omits the 'open_browser' parameter, leaving it unexplained. Thus, it only partially compensates for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Open' and the resource: 'local point clouds/meshes/splats/animated models together'. It differentiates from sibling open_3d_url by emphasizing 'local' and 'no implicit disk or network reads', making the tool's scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage instructions: 'Pass scene_id to append while preserving camera and existing objects' and requires explicit supporting .bin/textures for GLTF/DAE/FBX. It also states the root restriction. However, it does not explicitly contrast with alternatives like open_3d_url for remote files, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds genuinely useful runtime behaviors beyond the blank annotations: the gamma_correction toggle's exact meaning, the inclusion of enabled grid/legend in agent PNG captures, and the transient axis appearance when persistent axes are off. These are side effects and only explain this behavioral detail, though it would still be better to mention whether the set is reversible or if any combination is forbidden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: the first sentence leads with verb+resource and front-loads the main controls; the next two sentences add useful behavioral nuance. There is no fluff, though the dense listing style makes some mappings (exposure stops ↔ brightness) implicit.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is quite complete for a 9-parameter mutable tool with 0% schema: it covers the main fields and adds important capture/visible behavior. Missing pieces include the 'detail' parameter semantics and explicit mapping of 'brightness' to exposure; the presence of an output schema is not judged here as it does not require functionality that describes the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description carries most of the semantic burden, which it did: it maps axes/grid/legend/theme to their concepts, defines background as #RRGGBB, and thoroughly explains gamma_correction. However, the 'detail' parameter is completely undocumented in both schema and description, and 'brightness' is only indirectly hinted at by 'exposure stops' when clear parameter→meaning mapping.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') with a concrete resource ('3D appearance') and enumerates the exact aspects it controls: exposure stops, background, pivot axes, grid, legend, and UI theme. This clearly differentiates it from sibling tools like set_3d_camera or set_3d_object, which target different scene facets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for appearance-related adjustments but does not say explicitly when to use this tool versus alternatives, nor does it name sibling tools to avoid. The listed domains ('exposure stops, background, ... theme') give context, but an agent gets no direct when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds independent value with the mesh/splat null-index caveat and the explicit assurance about not moving the camera. It also discloses the return payload, which sets accurate expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with no filler. The core action and the most critical caveat are front-loaded, and every clause contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only pick tool with an output schema, a defaulted enum, and simple required params, the description covers the essential usage conditions and the important null-indices warning. The only minor gap is not explicitly explaining the 'detail' parameter, but the enum and the existence of an output schema mitigate the risk.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does for the 'screen' parameter by explaining 'normalized canvas XY,' which matches the 0..1 range constraints, but it does not explain 'scene_id' or clarify how 'detail' affects the output. The return-payload sentence hints at output content but does not connect it to the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Pick'), resource ('normalized canvas XY'), and the key behavior ('without moving the camera'), which distinguishes it from camera navigation and capture siblings. It also names the return fields, so an agent knows exactly what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'without moving the camera' phrasing gives clear context that this is a read-only picking operation rather than a navigation/capture tool. It does not explicitly name an alternative or provide when-not-to-use guidance, but the context is sufficient for selection among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnlyHint=false, openWorldHint=false, destructiveHint=false, leaving the description to carry behavioral detail. It discloses mutual exclusivity between fixed color and color_mode, explains adaptive point sizing behavior, and states the mesh requirement. It does not mention whether existing settings are overwritten or if there are side effects, but the description adds meaningful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but not bloated; each sentence adds essential information about a parameter or constraint. It is front-loaded with the core properties and then details specific modes and prerequisites. It could be slightly more structured (e.g., bullet points), but it remains efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 11 parameters and an output schema, and the description covers the majority of them meaningfully. However, it omits details on the 'detail' parameter (summary vs full) and does not explain scene_id/object_index beyond referencing inspection. Given the output schema exists and the description provides strong coverage of the most complex parameters, it is adequately complete but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only source of parameter meaning. It explains point_size_mode (adaptive vs fixed), the relationship between point_size_pixels and adaptive sizing, color_mode patterns, and the mutual exclusivity between color and color_mode. This is comprehensive and compensates fully for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets overlay opacity, visibility, point size, representation mode, and color properties on a 3D object. It is specific about the resource and actions, but it does not explicitly differentiate itself from sibling tools like set_3d_appearance or transform_3d_object, which could cause ambiguity for an agent choosing among them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides valuable usage context: it tells the agent to fetch object_index, scalar_fields, and available_color_modes from inspection before calling, and notes that mesh representation requires faces. It does not mention when to prefer this tool over siblings, but the given prerequisites and constraints are clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds valuable behavioral traits: view names are not persisted after closing/reloading, the undo stack is limited to 50 changes, and the tool does not restore geometry or filters. These details are not inferable from the schema or annotations and significantly inform the agent's expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with semicolons, efficiently packing purpose, scope, undo limit, persistence caveat, and exclusions. It is front-loaded with the core action and avoids redundancy. Every clause adds necessary information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which can explain return values) and a clear action enum, the description covers the essential behavioral context. It explains the main use cases and limitations, but could have mentioned the availability of list and delete actions to preempt ambiguity. Overall, it is sufficient for an agent to invoke the tool correctly, but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only hints at the 'name' parameter via 'named camera views' and implicitly covers 'action' with 'save/restore' and 'undo'. It does not mention the 'detail' parameter or other actions like 'list' and 'delete'. The description falls short of explaining the full parameter set, leaving the agent to rely on the schema enum values without additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb-resource pair: 'Save/restore named camera views' and 'undo the last agent camera change'. It clearly scopes to the renderer session and distinguishes from siblings like set_3d_camera and navigate_3d_view by focusing on named views and undo. The exclusion of geometry/filters further clarifies its boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (managing named camera views and undoing agent changes) and notes non-persistence across sessions. However, it does not explicitly name alternatives or state when not to use it, leaving some inference to the agent. It conveys usage context well but lacks direct exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses significant behavioral details beyond the annotations: partial-update semantics, rotation moving the target along camera -Z at the previous pivot distance, the exclusive-or constraint with target/up, fit behavior, and the return of the applied view state. This gives the agent a clear model of side effects without needing to infer them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences each add unique value with no filler or repetition. The primary action and parameter scope are front-loaded, and the nuanced constraints and return behavior are packed into the remaining sentences efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an 8-parameter camera mutation tool with an output schema, the description is complete enough for correct invocation: it covers partial update semantics, all key parameters, behavioral constraints, fit behavior, and the return value. The output schema can supply the remaining shape details, and the description adds the operational context needed beyond structured fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the full burden for explaining parameters. It explains rotation as absolute XYZ Euler degrees, FOV as degrees, and fit as framing visible geometry, while clarifying how target/up/position interact. However, scene_id is only inferable and the detail parameter is not explicitly described, though the return-state phrase hints at it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ("partially update") and identifies the exact resource and fields: camera position, target, up, and vertical FOV. It clearly differentiates the tool from siblings like set_3d_object or navigate_3d_view by scoping it to camera view parameters rather than scene objects or navigation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as navigate_3d_view, capture_3d_view, or manage_3d_views. The only usage-like instruction is the internal constraint that rotation cannot combine with target/up, which is about parameter combinations, not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate not read-only, not destructive, but the description adds key behavioral details: job is asynchronous and must be polled, submitted is not aligned, up_axis describes data not camera, partial failures are reported per object. It doesn't mention authorization requirements, but the description covers essential behaviors beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but organized, with a concise opening on polling and then enumerating actions. It front-loads the core workflow (start, poll) and then details each option. Some redundancy ('hold target fixed' repeated), but overall efficient for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 params, 6 actions, async behavior), the description is thorough: covers all actions, strategies, parameter semantics, edge cases (up_axis, selection clearing), and error reporting. Output schema exists, so return values are presumably covered there. No critical gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain each parameter's meaning and it does: source_index moves, target_index stays fixed, up_axis meaning, against_all_others behavior, strategy differences thorugh examples. It adds substantial semantic context for all 10 parameters, especially strategies and alignment modes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts a registration job and polls for status, with distinct modes (auto, icp, correspondences) and batch strategies. However, it does not explicitly differentiate from siblings like compare_3d_clouds or transform_3d_object, though it is specific to alignment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use each action (e.g., icp for close pairs, correspondences for landmark fitting), and notes when alternatives like align_all vs refine_all apply. Also mentions to clear temporary selections first, which is practical usage context. It clearly implies when not to use (e.g., no scale/nonrigid estimation).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=false and destructiveHint=false, so the description carries the burden and does it well. It discloses the 256 MiB cap, attribute preservation, object-local coordinates, header transform storage, return-type behavior, no-overwrite guarantee, and non-lossless numeric fidelity—all beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with no filler. The first sentence delivers the core action and primary constraint, while subsequent sentences add preservation details, coordinate behavior, return format, and caveats. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and sparse annotations, the description is notably complete: it covers operation, size limit, preserved attributes, coordinate frames, header contents, return shape, overwrite behavior, and fidelity caveat. Since an output schema exists, return-value structure need not be repeated. The only small gap is scene_id/path semantics, which does not undermine overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for missing parameter documentation. It does clarify that 'name' refers to a named subset and that output goes under configured roots, but it never explains the required scene_id parameter or the expected path format. This partial compensation is adequate but not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Write the active or named subset to a NEW binary .ply') and clearly distinguishes this from sibling tools like open_3d_files, capture_3d_view, or select_3d_region. The unique export-to-file purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended usage clear: export a selected 3D subset to a new .ply file, subject to size and overwrite constraints. It does not explicitly name alternatives or say when not to use it, but no sibling tool performs this export operation, so the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (only readOnlyHint, destructiveHint, openWorldHint), so the description carries the burden. It discloses several important behaviors: files never overwritten, max 20 states and 4 MiB each, JSON excludes geometry/playback, GLB excludes certain elements, export limit 256 MiB, and import/restore behavior. This far exceeds typical 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but densely packed with valuable information. It opens with the core purpose, then expands on export/import, constraints, and export_models specifics. Every sentence adds necessary detail; there's no filler. While it could benefit from bullet points, the paragraph format is efficient for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 actions, 6 params, output schema present), the description covers the essential behaviors: state saving/restoring, export/import persistence, limits, and export_models specifics. It doesn't detail return values, but the output schema handles that. Minor gaps include exact path syntax and detail parameter behavior, but these are inferable from the schema and context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains action values (save/restore/list/delete/export/import/export_models) and their nuances (e.g., export_models requires no name, restore=True applies immediately). It also clarifies path ('configured roots') and the detail parameter indirectly via the enum. Not every parameter is explicitly described, but key semantics are covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's scope: saving/restoring complete scene state (camera, transforms, selection, visibility, color, opacity, presentation) and exporting/importing JSON. It distinguishes itself from siblings like manage_3d_views (camera-only) and manage_3d_selections (selection-only) by covering all aspects. The mention of export_models adds a distinct capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong context on when to use this tool (full state management) and details specific behaviors like restore=True and export_models limitations. It doesn't explicitly name alternatives or state 'when not to use', but the scope is clear enough that an agent can infer when this is the appropriate tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With all annotation hints false, the description carries the full burden and does so thoroughly: it discloses calibration requirements, supported formats, optional auxiliary files, camera-append behavior via scene_id, COLMAP calibration sourcing, and the fact that picks/exports preserve original coordinates and raw values. This is rich behavioral context beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded with the core purpose, then efficiently covers formats, optional inputs, special modes, and diagnostic behavior. Every sentence carries useful information, though the length and reliance on domain-specific shorthand like 'viewer://depth-calibration' make it slightly less immediately digestible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with eight parameters, many formats, and special COLMAP behavior, the description covers the critical invocation details and references an output schema for results. It leaves minor gaps such as the exact default camera action when scene_id is omitted and the meaning of colmap_variant, but the overall context is strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although main-schema parameter descriptions are 0% covered, the description compensates by addressing path, rgb, confidence, mask, scene_id, colmap_image, and calibration behavior. The calibration object itself is well documented in the schema's $defs, so the main gap is colmap_variant, which is at least self-explanatory through its enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Project') and resource ('a depth/disparity raster inline'), and clarifies the tool's distinctive role among the 3D-viewer siblings: it loads depth/disparity rasters with explicit calibration, not general 3D files or scenes. It is immediately clear what this tool does and how it differs from tools like open_3d_files or read_viewer_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool, including optional RGB/confidence/mask inputs, the scene_id append behavior, and the special COLMAP dense-workspace mode with path=workspace and colmap_image. It does not explicitly name alternatives or state when not to use it, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint=false, openWorldHint=false, destructiveHint=false) and the description does not contradict them. It adds substantial behavioral context: the selection is reversible, it replaces prior selections, it has a highlight option, and it does not perform automatic segmentation. This goes well beyond the annotations and fully discloses the tool's side effects and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph of about 90 words. It front-loads the primary purpose, then adds behavioral notes. While it could benefit from bullet points for readability, every sentence contributes information and there is no fluff. It is concise given the tool's complexity (12 parameters) and well-structured logically.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is largely complete for an agent to use the tool correctly. It covers the selection criteria, reversibility, replacement behavior, point-cloud constraint, label ID caveat, and preview/highlight options. It lacks explicit detail on the return format (though 'PNG preview' is mentioned) and does not enumerate all parameters, but given the absence of an output schema and the tool's complexity, it provides sufficient context to avoid misinvocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It explains key parameter semantics: bounds corresponds to the world box, plane to the halfspace, values to scalar field intersections, and object_index to the object. It also mentions highlight (disable to preserve colors) and action (clear restores visibility). While not every parameter (e.g., detail, focus, isolate) is individually described, the core selection modes and critical options are covered, providing meaningful value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to select/isolate/focus points in a 3D scene with one step, offering multiple selection criteria (object, scalar field, world box, plane halfspace). It distinguishes itself from sibling tools like manage_3d_selections by emphasizing the 'one-step' and 'replaces previous selection' nature, making it obvious when to use it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it explains that selection is reversible ('clear restores prior visibility'), warns that label IDs are numeric (not semantic), notes the point-cloud-only limitation, and clarifies that it replaces the previous selection. While it doesn't explicitly name alternatives, it implies usage through phrases like 'one-step' and contrasts with more complex selection management, giving clear context for when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) by detailing the network request and redirect behavior, no CORS requirement, size limits (256 MiB default, 1 GiB max), timeouts (30s socket, 120s transfer), and cleanup (temporary files deleted when scene closes). It also discloses that login/cookies and webpage extraction are not supported, and that external resources are not fetched implicitly. This is thorough and consistent with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-organized paragraph that front-loads the primary action and then provides necessary details in a logical order: formats, network behavior, parameters, limits, and cleanup. Every sentence contributes substantive information—there is no filler or redundant restatement of the tool name or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (so return format is covered), the description addresses all essential aspects: input types, network semantics, limits, parameter usage, and lifecycle (temporary file deletion). It also mentions supported formats and gzip. An agent has everything it needs to decide when to use this tool and how to invoke it correctly without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining key parameters: filename is for extensionless/signed URLs, scene_id is to append to an existing scene, and max_bytes has a default and maximum (256 MiB / 1 GiB). It also clarifies that url can be a single string or an array. This adds meaning beyond the raw schema types and defaults, though it does not explicitly describe the url parameter's expected format beyond 'direct HTTP(S)'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise verb (download and open) and resource (HTTP(S) 3D files), and clarifies that it creates a scene or appends to one via scene_id. It clearly differentiates from sibling open_3d_files by focusing on remote URLs and network behavior, while explicitly noting that external resources are not fetched implicitly. This gives an agent a distinct mental model of the tool's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage context: it is for direct file URLs, not for webpage extraction or authenticated resources, and recommends self-contained models. It mentions that external resources are not fetched implicitly, implying that local files should go to a different tool, but it does not explicitly name alternatives or give hard when-to-use vs. when-not-to-use rules. Still, the guidance is clear enough for an agent to select it for URL-based 3D content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by explaining composition order, local vs world space, pivot resolution, undo depth, absolute replacement, and invert/reset behavior. These are exactly the non-obvious behavioral details an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but every sentence earns its place; no fluff or repetition. The most important scoping statement is front-loaded, and subtle coordinate-space/matrix details are packed efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 11-parameter transform tool, the description covers coordinate spaces, pivot centers, undo limits, absolute transforms, and verification steps. The output schema exists to handle return-value details, so the description is complete for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the full burden and succeeds: vector semantics, axis-angle behavior, quaternion normalization, column-major matrix layout, pivot defaults, and space composition are all explained precisely. Only minor details like the 'detail' parameter are left implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb and resource: 'Transform one cloud/mesh' with explicit non-goals ('without changing source files or camera'). It enumerates the action set and distinguishes the tool from appearance-related siblings by pointing to set_3d_object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use the tool and explicitly routes appearance work to set_3d_object. It also advises verifying with inspect local_to_world, though it does not enumerate a full when-not-to-use list for other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md: