Skip to main content
Glama

modules

Identify code clusters of symbols that call or reference each other. List all clusters or find which cluster a symbol belongs to.

Instructions

De-facto modules: clusters of symbols that call/reference each other (deterministic Leiden-CPM over call + ref + hierarchy edges, computed on full vex index). Without symbol: list clusters with a label (dominant path prefix; a bare file path when the cluster is a single file), size, cohesion and hub symbols. With symbol: that symbol's cluster and its members (limit caps the matching symbols). Use for what are the modules / which module is X in instead of reading directory listings. Requires a v9 index built by vex index; after vex update clusters are frozen and flagged stale. Returns an empty result with empty_reason and a hint on older indexes or when built with --no-clusters. Cluster ids are stable only within one full-index generation: do not persist them across vex index runs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoOrder clusters by in-scope size or by cohesion; ties by cluster id.size
limitNoMax clusters to list, or max matching symbols when `symbol` is given (per repo with `workspace`). Must be at least 1.
symbolNoSymbol whose cluster to show. Omit to list all clusters.
excludeNoBlacklist members by path glob; wins over include (repeatable)
includeNoWhitelist members by path glob, gitignore syntax (repeatable). A cluster is shown iff at least one member is in scope.
membersNoMembers to list per cluster, ordered by path then line (default: 0 when listing, 25 for a `symbol` lookup). Must be in `[0, 10000]`.
min_sizeNoHide clusters with fewer in-scope symbols than this. List mode only; ignored when `symbol` is given. Must be in `[1, 1000000]`.
workspaceNoMulti-repo: fan out across every repo declared in the nearest `.vex-workspace.toml` (set `project_root` at or above it — the manifest is found by walking up). Results become an object `{workspace, repos:[...]}` grouped by repo, NOT the flat per-tool array — branch on shape. `why` is ignored in workspace mode (single-repo only).
auto_updateNoAuto-update the index if stale, or bootstrap it if missing, before running (default: true)
async_updateNoWith auto_update, refresh a stale index in the background instead of waiting for it: results come from the index already on disk and _meta.vex.dev/stale says so (default: false)
project_rootNoAbsolute path to the project root (defaults to the MCP working directory)
exclude_testsNoDrop test files from the results (tests/ dirs, *_test.*, test_*.py, *.spec.ts, __tests__/, tests.rs, ...; same set as tests_for). Composes with include/exclude. Path-based only: Rust unit tests inside a `#[cfg(test)] mod tests` block of a non-test file are not excluded.
no_stale_checkNoSkip the staleness check that runs before each call; assumes the index is fresh. Redundant when `auto_update` is true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.27.3

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it states the v9 index prerequisite, the stale/frozen behavior after `vex update`, the empty-result contract with `empty_reason` and hints for old or `--no-clusters` indexes, and the critical caveat that cluster ids are stable only within one full-index generation and must not be persisted. This is exactly the behavioral context 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.

Conciseness4/5

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

Front-loaded with the core definition and mode split, then prerequisites and caveats. Dense and information-rich with little waste, though a few sentences (id stability, empty_reason) are packed into long clauses that could be split for faster scanning.

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 13-parameter, no-annotation, no-output-schema tool, the description covers purpose, both operating modes, prerequisites, failure/empty behavior, and stability caveats. Nothing essential to correct invocation is missing.

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%, so the schema already documents all 13 parameters (baseline 3). The description still adds value by clarifying `limit`'s dual meaning (clusters vs matching symbols), the omit-`symbol`-to-list semantics, and the shape change in `workspace` mode, going beyond the schema text.

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+resource ('De-facto modules: clusters of symbols that call/reference each other') and even names the algorithm (deterministic Leiden-CPM over call + ref + hierarchy edges). An agent can distinguish this from directory-listing or symbol-lookup siblings without opening the schema.

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

Usage Guidelines5/5

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

Gives explicit routing: 'Use for `what are the modules` / `which module is X in` instead of reading directory listings.' It also splits behavior by the `symbol` argument (omit to list clusters, provide to get one cluster's members), so the agent knows exactly which mode to pick.

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