Skip to main content
Glama

cluster

Group rows in a table or embedding into labeled segments, add a color_by label column for plots, and write embedding labels back to the parent table.

Instructions

Cluster a table (or an embedding) and add a label column (cluster_) usable as color_by in plot. If run on an embedding, labels are also written back to the parent table. methods: kmeans (k omitted -> silhouette over 2..k_max, with the whole silhouette-by-k table, the Calinski-Harabasz choice and the finest k within 10% of the best, because silhouette favours coarse splits), gmm (k by BIC), dbscan (eps from 5-NN distances), hdbscan, agglomerative. standardize 'auto'/True/False and clip_z as in project. Returns sizes (with a warning when clusters hold <0.5% of rows: outliers, not groups), silhouette, Davies-Bouldin and each cluster's centroid signature (features most displaced from the global mean, in SD units).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "cluster"
  }
}

Input Schema

NameRequiredDescriptionDefault
kNo
nameYes
seedNo
k_maxNo
clip_zNo
methodNokmeans
paramsNo
featuresNo
label_colNo
standardizeNoauto

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations at all, the description carries the full burden and does substantial work: it discloses the write-back side effect (labels written to the parent table when run on an embedding), the k-selection heuristics per method, the <0.5% cluster warning semantics, and the returned metrics. Determinism (the seed param), cost on large tables, and overwrite behavior of label_col remain undisclosed.

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?

Purpose and output are front-loaded, and every clause carries information rather than filler. The heavy parenthetical nesting makes it a single dense block that is harder to scan than it needs to be, but little can be cut without losing content.

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

Completeness4/5

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

For a 10-parameter pipeline tool it is close to complete: it covers method semantics, side effects, warnings, and even return contents despite an output schema existing. Gaps are the undocumented name/label_col/features/seed parameters and the unhelpful 'as in project' cross-reference for clip_z and standardize, which forces the agent to consult a sibling tool.

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

Parameters3/5

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

Schema description coverage is 0% across 10 parameters, so the description must compensate. It meaningfully explains method (five named options), k and k_max (silhouette over 2..k_max; BIC for gmm), standardize ('auto'/True/False) and clip_z, but leaves name, label_col, features, seed and the method-specific params object entirely unexplained.

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?

States a specific verb and resource ('Cluster a table (or an embedding)') plus the concrete artifact it produces: a label column named cluster_<method> usable as color_by in plot. That output signature makes it unmistakable against siblings like project, neighbors, or plot without opening any schema.

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 explains the internal decision logic of each method (silhouette sweep for kmeans, BIC for gmm, 5-NN eps for dbscan), which implicitly guides method selection. It never states when *not* to use this tool or names an explicit alternative (e.g. use project for dimensionality reduction instead), so routing to siblings is left to inference.

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