Skip to main content
Glama
Sign In
Graph-Memory

Graph-Memory

by stevepridemore
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Detect Knowledge Communities

graph_communities
Read-only

Find clusters of densely-interconnected entities in a knowledge graph to reveal topic neighbourhoods. Assigns each entity to one community and returns clusters plus coverage stats, without needing GDS or APOC.

Instructions

Find clusters of densely-interconnected entities in the graph. Uses greedy seed-based BFS through edges above the weight threshold — works without GDS or APOC. Each entity is assigned to at most one community (the first that reaches it from a high-degree seed). Useful for understanding knowledge neighbourhoods (e.g. "everything related to infrastructure"). Returns {communities, coverage}. communities holds at most max_communities clusters in seed order (highest-degree seed first), each shaped {id, seed_name, seed_id, member_count, dominant_type, members: [{id, name, type}]} with at most 30 members listed; communities below min_size are left out. coverage is {total_entities, assigned, unassigned}. Use graph_query or graph_search instead when you have a specific entity to start from.

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": "graph_communities"
  }
}

Input Schema

NameRequiredDescriptionDefault
max_hopsNoBFS depth from each seed (default 3, capped at 4).
min_sizeNoMinimum members for a community to be returned (default 2).
max_communitiesNoMaximum number of communities to return (default 10).
weight_thresholdNoOnly traverse edges with weight strictly greater than this (default 0.4).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.2
  2. Removedv0.1.4
  3. First observedv1.0.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true; the description adds substantial context beyond that — the greedy seed-based BFS algorithm, the fact that no GDS/APOC is required, the exclusive-assignment rule (each entity joins the first community that reaches it from a high-degree seed), the hard cap of 30 listed members, and the exclusion of communities below min_size. These are exactly the behavioral traits an agent needs to interpret results correctly.

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 purpose and algorithm, then the return shape, then the alternative-tool routing — a sensible order. It is dense rather than padded, though the long parenthetical schema sketch of the community object is heavier than strictly necessary and could have been tightened.

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?

There is no output schema, so the description carries the full burden of explaining returns and does so precisely: the top-level `{communities, coverage}` shape, each community's fields, the 30-member truncation, and the `{total_entities, assigned, unassigned}` coverage counters. Nothing an agent needs to call or interpret this tool 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 baseline is 3, but the description adds real meaning: it explains that communities come back 'in seed order (highest-degree seed first)', that communities below min_size are dropped, and that member lists are truncated at 30 regardless of member_count. max_hops and weight_threshold are only lightly echoed beyond the schema, which keeps this short of a 5.

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 ('Find clusters of densely-interconnected entities in the graph') and immediately distinguishes itself from the traversal siblings by naming graph_query and graph_search. An agent can tell this is a whole-graph community-detection tool rather than a lookup tool 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 Guidelines5/5

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

Gives a concrete use case ('understanding knowledge neighbourhoods, e.g. everything related to infrastructure') and an explicit exclusion rule: use graph_query or graph_search when you already have a specific entity to start from. That is a clear when-to-use and when-not-to-use routing decision.

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

Deploy Server

Other Tools