Skip to main content
Glama

compute_clusters

Computes live connected-component vector clusters for StarSystems or CelestialBodies across cosmic structures without modifying the database, enabling similarity grouping for research.

Instructions

Compute live connected-components vector clusters for StarSystems or CelestialBodies across cosmic structures without modifying the database.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

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

Input Schema

NameRequiredDescriptionDefault
forceNoBypass Rails memory cache and recalculate adjacency graph
levelNoSimilarity granularity level from 1 (strict twins, <= 0.16 cosine dist) to 15 (full coverage absorption, <= 0.30)
target_typeNoTarget entity class to cluster: StarSystem or CelestialBodyStarSystem
full_coverageNoForces 100% catalog assignment / zero singletons via nearest-cluster absorption

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations supplied, the description carries the full burden, and it does deliver one meaningful disclosure: 'without modifying the database' tells the agent this is non-destructive. It does not say whether computed clusters are persisted, how long a full recomputation takes, or whether permissions or embeddings must already exist, which matters for a compute-heavy operation.

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?

It is a single front-loaded sentence with the action first and the non-destructive guarantee second, with no redundant restatement of the name. 'Across cosmic structures' is slightly vague filler, but overall it is tight.

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?

There is no output schema and no annotations, so the description should say something about what comes back - cluster group objects, assignments, singleton counts - and it does not. Combined with no usage routing against the cluster-group read tools, the definition is adequate but leaves real gaps for a compute tool with four parameters.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter (force, level, target_type, full_coverage) is already documented in the schema with defaults and enum values; baseline is 3. The description adds no parameter-specific semantics beyond restating the general 'clusters for StarSystems or CelestialBodies' scope.

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

Purpose4/5

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

The description gives a specific verb and resource: 'compute live connected-components vector clusters' for 'StarSystems or CelestialBodies'. It is clear what the tool produces, but it makes no reference to any sibling (e.g. list_cluster_groups or get_cluster_group), so an agent cannot immediately tell whether to read persisted clusters or compute them here.

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?

There is no explicit when-to-use or when-not-to-use guidance and no alternatives are named. The phrase 'live ... without modifying the database' hints that this is a read-only recomputation path, but the agent must infer the scenario (e.g. freshly computing clusters instead of fetching existing ones) on its own.

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