What can you do with this server?

This server enables AI assistants to process, analyze, and manipulate 3D point clouds and meshes via natural language using CloudCompare (MCP). * Check Installation (get_cloudcompare_info): Verify CloudCompare is installed, retrieve its version and path. * Inspect Files (load_cloud_info / read_cloud_metadata): Return point count, bounding box, extent, density, and scalar field presence (RGB, intensity, normals). * Visualize Clouds (visualize_cloud): Render top/front/side views as base64 PNG with color modes: height, rgb, intensity. * Subsample (subsample): Reduce density via random, spatial, or octree methods. * Cloud-to-Cloud Distances (compute_cloud_to_cloud_distances): Calculate nearest-neighbor distances between two clouds. * Cloud-to-Mesh Distances (compute_cloud_to_mesh_distances): Compute signed distances from a point cloud to a reference mesh (e.g., scan vs. CAD). * ICP Registration (icp_registration): Align two clouds iteratively, returning the transformation matrix and RMS error. * Normal Estimation (compute_normals): Estimate surface normals using LS, quadric, or triangulation methods. * Scalar Field Filtering (filter_by_scalar_field): Keep points within a scalar value range (height, intensity, distance, etc.). * Outlier Removal (statistical_outlier_removal): Remove noise using a k-nearest-neighbor statistical filter. * Merge Clouds (merge_clouds): Combine multiple point clouds into one. * Format Conversion (convert_format): Convert between LAS, LAZ, PLY, PCD, XYZ, ASC, TXT, E57, OBJ, BIN, SHP. * Custom Commands (run_cloudcompare_command): Execute arbitrary CloudCompare CLI commands for advanced operations.

How do I use cloudcompare-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cloudcompare-mcp Load scan.las and subsample spatially to 5 cm" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

cloudcompare-mcp

by yufeioptimal

Overview Schema Related Servers Score Discussions

Python

Local

cloudcompare-mcp

Cross-platform Model Context Protocol (MCP) server for CloudCompare — lets AI assistants (Claude, etc.) process 3D point clouds and meshes via natural language.

Features

Native tools (no CloudCompare required)

Tool	Description
`read_cloud_metadata`	Parse a cloud and return point count, bounding box, extent, density, RGB/intensity/normals presence
`visualize_cloud`	Render top / front / side views + metadata panel as a base64 PNG the model can see directly

CloudCompare tools (requires CloudCompare installation)

Tool	Description
`get_cloudcompare_info`	Check installation & version
`load_cloud_info`	Inspect file stats via CloudCompare
`subsample`	Reduce density — random / spatial / octree
`compute_cloud_to_cloud_distances`	C2C nearest-neighbour distances
`compute_cloud_to_mesh_distances`	C2M signed distances
`icp_registration`	Align two clouds with ICP
`compute_normals`	Estimate surface normals
`filter_by_scalar_field`	Threshold points by scalar value
`statistical_outlier_removal`	Remove noise with SOR filter
`merge_clouds`	Merge multiple clouds into one
`convert_format`	Convert between LAS/LAZ, PLY, PCD, XYZ, E57, OBJ…
`run_cloudcompare_command`	Escape hatch for arbitrary CLI commands

How `visualize_cloud` works

visualize_cloud reads the point cloud natively in Python, renders a 4-panel figure, and returns an ImageContent (base64 PNG) alongside a JSON description. The model can see the image directly — no display or CloudCompare needed.

┌─────────────────┬─────────────────┐
│   Top  (XY)     │   Front  (XZ)   │
│                 │                 │
├─────────────────┼─────────────────┤
│   Side  (YZ)    │  Metadata stats │
│                 │  (pts, bbox,    │
│                 │   density, …)   │
└─────────────────┴─────────────────┘

Color modes: height (viridis Z gradient, default) · rgb (stored RGB) · intensity (plasma).

Related MCP server: FreeCAD MCP Server

Requirements

Python ≥ 3.10
uv (recommended) or pip
CloudCompare ≥ 2.12 — download (only for CloudCompare tools)

Python dependencies installed automatically: numpy, matplotlib, laspy[lazrs], plyfile.

Installation

Quickstart with `uvx` (no install needed)

uvx cloudcompare-mcp

Install locally

pip install cloudcompare-mcp
cloudcompare-mcp

CloudCompare binary detection

The server looks for CloudCompare in this order:

CLOUDCOMPARE_PATH environment variable
System PATH (cloudcompare / CloudCompare)
Platform default locations:

Platform	Default path
macOS	`/Applications/CloudCompare.app/Contents/MacOS/CloudCompare`
Windows	`C:\Program Files\CloudCompare\cloudcompare.exe`
Linux	`/usr/bin/cloudcompare`

Set CLOUDCOMPARE_PATH to override:

export CLOUDCOMPARE_PATH="/opt/custom/cloudcompare"

MCP client configuration

Claude Desktop (`claude_desktop_config.json`)

{
  "mcpServers": {
    "cloudcompare": {
      "command": "uvx",
      "args": ["cloudcompare-mcp"]
    }
  }
}

Claude Code (`~/.claude/settings.json`)

{
  "mcpServers": {
    "cloudcompare": {
      "command": "uvx",
      "args": ["cloudcompare-mcp"]
    }
  }
}

With a custom binary path:

{
  "mcpServers": {
    "cloudcompare": {
      "command": "uvx",
      "args": ["cloudcompare-mcp"],
      "env": {
        "CLOUDCOMPARE_PATH": "/path/to/cloudcompare"
      }
    }
  }
}

Usage example

Once configured in Claude Desktop or Claude Code:

"Load my scan.las file and subsample it spatially to 5 cm, then remove statistical outliers."

Claude will call the appropriate tools in sequence and report results.

Supported file formats

LAS · LAZ · PLY · PCD · XYZ · ASC · TXT · E57 · OBJ · BIN · SHP

License

MIT

Available Tools

12 tools

compute_cloud_to_cloud_distancesA

Compute nearest-neighbour distances from every point in the 'compared' cloud to the 'reference' cloud (C2C distance). Returns distance statistics and saves the labelled cloud.

ParametersJSON Schema

Name	Required	Description
`reference_path`	Yes	Absolute path to the reference point cloud.
`compared_path`	Yes	Absolute path to the compared point cloud.
`output_path`	Yes	Absolute path for the compared cloud with distance scalar field.
`max_distance`	No	Maximum search distance (optional, in metres).

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses it saves labelled cloud and returns statistics; no annotations so description carries weight. Lacks details on returned statistics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words, front-loaded purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for 4-param tool with no output schema; could explain 'labelled cloud' and statistics format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers all parameters fully; description adds no new semantic nuances beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it computes C2C distances from compared to reference cloud, and distinguishes from mesh variant sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or alternatives guidance; sibling name implies difference but description doesn't elaborate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compute_cloud_to_mesh_distancesA

Compute signed distances from a point cloud to a reference mesh (C2M distance). Useful for comparing a scan to a CAD model.

ParametersJSON Schema

Name	Required	Description
`mesh_path`	Yes	Absolute path to the reference mesh (OBJ, PLY, etc.).
`cloud_path`	Yes	Absolute path to the compared point cloud.
`output_path`	Yes	Absolute path for the labelled output cloud.

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must fully disclose behavior. It only says 'compute signed distances' without mentioning side effects, destructiveness, or what signed distances imply (e.g., positive vs negative). Does not state if files are modified or created.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences that front-load the action and purpose. Every word contributes meaning; no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the main purpose and a use case, but omits details about the output (e.g., that it saves a labelled cloud to output_path) and does not explain the return value or any side effects. Given the simplicity, it is adequate but incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are already well-described. The description adds the concept of 'signed distances' and 'C2M' context, but does not provide additional semantic details beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the action (compute signed distances), resources (point cloud and reference mesh), and acronym (C2M). Distinguishes from sibling compute_cloud_to_cloud_distances which compares two point clouds.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a use case ('comparing a scan to a CAD model') but no explicit guidance on when to use this tool versus alternatives, nor when not to use it. Lacks prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compute_normalsA

Estimate surface normals for a point cloud using a local neighbourhood. Normals are required for many downstream operations (Poisson reconstruction, etc.).

ParametersJSON Schema

Name	Required	Description	Default
`input_path`	Yes	Absolute path to the input point cloud.
`output_path`	Yes	Absolute path for the cloud with normals.
`mode`	No	Normal estimation mode. LS=Least Squares (default).	LS
`radius`	No	Neighbourhood radius in metres. Mutually exclusive with knn.
`knn`	No	K nearest neighbours. Mutually exclusive with radius.

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as whether the operation is destructive, required permissions, side effects, or error handling. The description is too brief for a writing operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences, front-loaded with the core purpose, and contains no superfluous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters and no output schema, the description covers purpose and general usage but lacks details about output behavior, default values (beyond mode), and error conditions. It is adequate but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds context about 'local neighbourhood' but does not add significant meaning beyond the schema descriptions, which already explain radius and knn.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool estimates surface normals for a point cloud using a local neighbourhood, with a specific verb and resource. It distinguishes from siblings like compute_cloud_to_cloud_distances by its unique function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions that normals are required for downstream operations, implying when to use, but does not provide explicit guidance on when not to use or compare to alternatives. The context is helpful but minimal.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

convert_formatA

Convert a point cloud or mesh file to a different format. CloudCompare infers the target format from the output file extension (e.g. .las, .laz, .ply, .pcd, .xyz, .asc, .e57, .obj).

ParametersJSON Schema

Name	Required	Description	Default
`input_path`	Yes	Absolute path to the input file.
`output_path`	Yes	Absolute path for the output file (extension defines format).

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description provides one key behavioral detail (format inference from extension) but omits other important behaviors like file overwrite policy or input preservation. This leaves gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no wasted words. The key information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given low complexity (two params, no output schema), the description covers essential aspects. Minor omissions like error handling do not significantly impair completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear param descriptions. The description adds value by explaining format inference and listing examples, which is beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool converts point cloud or mesh files to different formats, with specific examples. It is distinct from sibling tools which perform different operations like distance computation or filtering.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly indicates when to use (format conversion needed) but lacks explicit exclusions or alternatives. However, the narrow purpose makes the usage context clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

filter_by_scalar_fieldA

Keep only points whose scalar-field value falls within [min_val, max_val]. Useful for height, intensity, or distance thresholding.

ParametersJSON Schema

Name	Required	Description
`input_path`	Yes	Absolute path to the input point cloud.
`output_path`	Yes	Absolute path for the filtered cloud.
`min_val`	Yes	Minimum scalar field value to keep.
`max_val`	Yes	Maximum scalar field value to keep.

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully communicate behavior. It only describes the filtering action but omits whether the operation is destructive, modifies input files, or has performance implications. The agent lacks necessary transparency for safe invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences, front-loaded with the core action. Every word adds value, with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the essential function but lacks details on output (no output schema), side effects, or error conditions. For a simple filter tool, it is minimally adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with each parameter described. The description adds examples of scalar fields (height, intensity, distance), providing slight additional context beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool filters points by scalar field within a range, with specific use cases like height, intensity, or distance thresholding. No sibling tool performs similar filtering, making it distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context on when to use it (e.g., height thresholding), but lacks explicit when-not-to-use or alternative tools. However, the purpose is clear from the examples.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_cloudcompare_infoA

Check if CloudCompare is installed and return its version and path. Call this first to confirm the tool is available.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Describes the operation as a read-only check returning version and path. Adequate but does not specify error behavior (e.g., if not installed) or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with action and purpose. No extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, simple check tool with no output schema, the description sufficiently covers purpose, usage timing, and return information. No gaps given the low complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters in schema, baseline 4 applies. Description adds value by specifying what will be returned (version and path), but does not explain parameter intent since there are none.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb ('check if installed') and resource ('CloudCompare') with specific outputs (version, path). Uniquely identifies itself as a prerequisite check distinct from sibling tools that perform actual operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states 'Call this first to confirm the tool is available.' Provides clear timing context but does not exclude other uses or mention alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

icp_registrationB

Register a 'data' cloud onto a 'model' cloud using the Iterative Closest Point (ICP) algorithm. Returns the transformation matrix and final RMS error.

ParametersJSON Schema

Name	Required	Description
`model_path`	Yes	Absolute path to the fixed reference cloud.
`data_path`	Yes	Absolute path to the cloud to be aligned.
`output_path`	Yes	Absolute path for the aligned cloud.
`overlap`	No	Expected overlap percentage between clouds (10–100). Default 100.
`iterations`	No	Maximum ICP iterations. Default 20.
`random_sampling_limit`	No	Number of points used during ICP (speeds up large clouds). Default 50000.

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It mentions output but does not indicate side effects (e.g., writes aligned cloud to output_path), whether it is destructive, or any rate limits. Lacks details on failure modes or required data types.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is a single sentence, concise and front-loaded with purpose. However, it omits necessary behavioral details, so it's slightly under-specified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 6 parameters and no annotations or output schema, the description is incomplete. It explains high-level purpose but lacks details on parameter usage, error cases, and prerequisites, which could confuse an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. Description adds context about ICP algorithm and output, but does not explain individual parameters like overlap, iterations, or random_sampling_limit beyond what schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verb 'Register' and clarifies it's for aligning data clouds onto model clouds using ICP. It distinguishes from siblings like 'compute_cloud_to_cloud_distances' which measures distances, not alignment. Outputs (transformation matrix, RMS error) are clearly stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus siblings. The description does not mention prerequisites, when not to use, or alternative tools for similar tasks.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

load_cloud_infoA

Load a point cloud or mesh file and return basic statistics: number of points, bounding box, available scalar fields, etc. Supports LAS/LAZ, PLY, PCD, E57, XYZ, ASC, BIN, SHP, OBJ, and more.

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes	Absolute path to the point cloud or mesh file.

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. The description discloses return values (points, bounding box, fields) but does not discuss side effects, permissions, or error handling. Adequate for a read-like operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no redundant information. Key details are front-loaded: load, return statistics, supported formats.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool without output schema, the description adequately explains input (file path plus formats) and what statistics will be returned, covering all essential information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description covers 100% of the single parameter. The description adds supported file formats, providing useful context beyond the schema's path description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool loads a file and returns basic statistics, listing supported formats. It distinguishes from sibling tools like compute or filter 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/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for obtaining basic statistics but does not explicitly state when to use this tool over alternatives like get_cloudcompare_info or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

merge_cloudsB

Merge two or more point cloud files into a single output file.

ParametersJSON Schema

Name	Required	Description	Default
`input_paths`	Yes	List of absolute paths to the input point clouds.
`output_path`	Yes	Absolute path for the merged cloud.

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose behavioral traits such as memory usage, file size limits, whether input files are modified, or required formats. For a file operation, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no unnecessary words. It is efficient but could benefit from additional context without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description does not explain what the tool returns (e.g., success/failure, output path). It also lacks details on side effects or operational context, which limits completeness for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with both parameters described. The description repeats 'absolute paths' and 'merged cloud' which are already in the schema, adding no new semantic value beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (merge) and the resource (point cloud files) with a specific output (single output file). It distinguishes from sibling tools like conversion or filtering, which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives such as subsample or convert_format. The description does not mention context, prerequisites, or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_cloudcompare_commandA

Run an arbitrary CloudCompare CLI command for advanced or unsupported operations. Do NOT include the executable path or -SILENT flag — they are added automatically. Example args: ["-O", "/path/cloud.las", "-AUTO_SAVE", "OFF"]

ParametersJSON Schema

Name	Required	Description	Default
`args`	Yes	CloudCompare CLI arguments (after the binary and -SILENT).
`working_directory`	No	Optional working directory for the command.

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that the executable path and -SILENT are added automatically, but does not mention output format, error handling, or potential risks, which are important for arbitrary command execution.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences that cover purpose and a key usage guideline. Every word is essential with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of running arbitrary commands, the description lacks critical information such as what output is returned (e.g., stdout/stderr), success/failure indicators, and potential risks. No output schema is provided, so the description should compensate but does not.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds value by providing an example and explicitly stating what not to include, which goes beyond the schema's description of arguments 'after the binary and -SILENT'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Run an arbitrary CloudCompare CLI command' with a specific verb and resource. It distinguishes itself from siblings by targeting advanced/unsupported operations, as siblings like compute_cloud_to_cloud_distances are specific known tasks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit guidance on what not to include (executable path and -SILENT). While it implies usage for cases not covered by siblings, it does not explicitly state when to use or provide alternatives, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

statistical_outlier_removalA

Remove statistical outliers by analysing the distance distribution to k nearest neighbours. Points farther than (mean + nSigma × std) from their neighbours are removed.

ParametersJSON Schema

Name	Required	Description
`input_path`	Yes	Absolute path to the input point cloud.
`output_path`	Yes	Absolute path for the cleaned cloud.
`knn`	No	Number of nearest neighbours to consider. Default 6.
`n_sigma`	No	Sigma multiplier for outlier threshold. Default 1.0.

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the burden. It explains the removal criterion (mean + nSigma*std) and implies destructive behavior (points removed). However, it does not disclose whether the input file is modified, output overwriting behavior, or potential side effects like memory usage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, direct and front-loaded with the purpose. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the core algorithm but lacks contextual details like typical parameter values, statistical assumptions (e.g., Gaussian distribution), or prerequisites (e.g., point cloud format). Adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are well-documented in the schema. The description adds a formula referencing knn and n_sigma but no extra constraints or examples. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'remove', the resource 'statistical outliers', and the specific algorithm (distance distribution to k nearest neighbors, threshold mean + nSigma*std). This distinguishes it from sibling tools like filter_by_scalar_field or icp_registration.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives (e.g., filter_by_scalar_field), nor does it mention prerequisites or when not to use it. Only the algorithm is explained.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

subsampleA

Reduce the density of a point cloud using random, spatial, or octree subsampling. Output is saved to the specified path.

ParametersJSON Schema

Name	Required	Description	Default
`input_path`	Yes	Absolute path to the input point cloud.
`output_path`	Yes	Absolute path for the output file.
`method`	No	Subsampling method.	SPATIAL
`parameter`	Yes	RANDOM: number of points to keep (int). SPATIAL: minimum spacing between points (metres). OCTREE: octree subdivision level (1–21).

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must disclose behavior. It only states output is saved to a path, lacking details on side effects, performance, or failure modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no redundant words, front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks guidance on method selection, error conditions, and output format. Adequate for a simple tool but could be more comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds minimal value beyond schema; it reiterates method options without further clarification.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reduces point cloud density using three specific methods, distinguishing it from sibling tools like merge_clouds or filter_by_scalar_field.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use subsampling vs other filtering tools. The purpose is implied but no exclusions or alternatives are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a distinct operation (e.g., distance computation, filtering, registration, conversion), with clear differentiation even between similar tools like cloud-to-cloud and cloud-to-mesh distances.

Naming Consistency4/5

Most tools follow a `verb_noun` pattern with underscores, but 'icp_registration' and 'statistical_outlier_removal' deviate slightly by starting with a noun/adjective instead of a verb.

Tool Count5/5

With 12 tools covering loading, filtering, registration, distance analysis, and format conversion, the set is well-scoped for point cloud processing without being overwhelming or too sparse.

Completeness5/5

The tool set covers essential point cloud operations comprehensively, and the inclusion of an arbitrary command execution tool ('run_cloudcompare_command') fills any potential gaps, ensuring no dead ends.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

QCDatabase.AI
ai.qcdatabase
Connects AI assistants to QCDatabase.AI for everyday construction quality-control work.
Databases Project Management
1
OpenClaw Direct AOAuth
direct.openclaw
Deploy, monitor, and manage your OpenClaw AI assistants via natural language.
Agent Orchestration Autonomous Agents Monitoring
2
Caliper A
fit.caliper
Geometry and CAD file metadata extraction for STL, OBJ, PLY, PCD, LAS/LAZ, glTF/GLB.
Design Tools Software Architecture
102
ScanBIM MCP A
io.scanbimlabs
AI Hub for AEC — 50+ 3D formats, clash detection, ACC integration via Autodesk Platform Services.
AI & Machine Learning Design Tools
192

Related MCP Servers

CLO3D MCP Server
Design Tools Autonomous Agents
Ubani-Studio
A
license
Not graded
quality
D
maintenance
Enables AI assistants to control CLO3D for pattern creation, fabric swapping, simulation, and model export via natural language commands.
Updated a month ago (2026-07-29 19:12 UTC)
20
MIT
FreeCAD MCP Server
Design Tools Autonomous Agents
tomo1230
A
license
C
quality
D
maintenance
Allows AI agents like Claude to create, edit, and query 3D models in FreeCAD through natural language.
Updated 5 months ago (2026-04-09 05:57 UTC)
57
6
MIT
Civil 3D MCP Server
Design Tools Autonomous Agents
DaniGhosy
A
license
A
quality
B
maintenance
Enables AI assistants to interact with Autodesk Civil 3D through natural language, supporting tools for surfaces, alignments, profiles, corridors, pipe networks, COGO points, and AutoCAD geometry.
Updated 16 days ago (2026-08-18 19:17 UTC)
9
2
MIT
PointCloud MCP
Image & Video Processing Research & Data
feelgom
F
license
Not graded
quality
C
maintenance
Enables querying 3D point cloud files (PLY/PCD) using natural language. Provides tools for point cloud description, plane detection, and ICP alignment.
Updated 2 months ago (2026-07-14 12:53 UTC)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/yufeioptimal/cloudcompare-mcp'

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

cloudcompare-mcp

Features

Native tools (no CloudCompare required)

CloudCompare tools (requires CloudCompare installation)

How visualize_cloud works

Requirements

Installation

Quickstart with uvx (no install needed)

Install locally

CloudCompare binary detection

MCP client configuration

Claude Desktop (claude_desktop_config.json)

Claude Code (~/.claude/settings.json)

Usage example

Supported file formats

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

How `visualize_cloud` works

Quickstart with `uvx` (no install needed)

Claude Desktop (`claude_desktop_config.json`)

Claude Code (`~/.claude/settings.json`)