Skip to main content
Glama
Sign In
kernl

kernl

by fastslack
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

kernel_graph_analyze

Computes pagerank, communities, components, or betweenness on selected labels and writes the scores to nodes. Use the results in graph queries to rank central nodes, group communities, or find bridges.

Instructions

Graph analytics over the labels you name (and, optionally, only some relationship types): pagerank (who is central), communities (Louvain groups), components (what is connected at all), betweenness (who bridges groups). The result is written on each node as pageRank (pagerank), communityId (communities), componentId (components), betweenness (betweenness) — use it afterwards in kernel_graph_query, e.g. ORDER BY p.pageRank DESC. Runs on Graph Data Science when the graph has it or GDS_REMOTE_URI points at one (only numbered nodes and edges are sent), otherwise in the kernel, up to 200000 nodes.

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": {
      "algorithm": "<algorithm>",
      "labels": "<labels>"
    },
    "name": "kernel_graph_analyze"
  }
}

Input Schema

NameRequiredDescriptionDefault
topNo
writeNoWrite the result on the nodes.
engineNoauto
labelsYesNode labels to include, e.g. ["Person"].
algorithmYes
relationshipsNoRelationship types to follow; all by default.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.1

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full disclosure burden and does well: it says results are persisted onto nodes under specific property names, discloses the execution engine selection logic and the data-egress detail that 'only numbered nodes and edges are sent' to a remote GDS, and states a hard cap of 200000 nodes. It does not cover permissions, runtime/cost, or whether existing properties are overwritten.

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 is front-loaded and every clause carries information, but the single dense paragraph packs algorithm listing, property-name mapping, engine logic, and limits into one block, making it harder to scan than a short bulleted structure would be. No sentence is wasted, though.

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 six-parameter analytics tool with an output schema, the definition covers the important agent-facing facts: what each algorithm produces, where the result lands, how to consume it afterwards, engine/remote behavior, and the node cap. Remaining gaps are minor (the `top` parameter and failure modes), which the output schema partly offsets.

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 50%, and the description compensates for most of the gap: it explains each algorithm value, that `labels` scopes the node set, that `relationships` optionally narrows edge types, and that the result is written onto nodes (relevant to `write`). The `engine` values are partially illuminated by the GDS/GDS_REMOTE_URI/local sentence, but `top` is never explained and the engine enum values are not mapped explicitly, so it falls short of full compensation.

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 states a specific verb and resource (graph analytics over named labels) and immediately enumerates the four algorithms with a one-phrase gloss for each ('who is central', 'Louvain groups', 'what is connected at all', 'who bridges groups'). It also distinguishes this tool from its closest sibling by naming kernel_graph_query as the downstream consumer of the computed properties.

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?

Usage is clear: run an algorithm here, then read the written properties via kernel_graph_query with e.g. 'ORDER BY p.pageRank DESC'. The per-algorithm glosses effectively guide algorithm selection. There is no explicit when-not guidance (e.g. when to prefer kernel_graph_ask or kernel_graph_slice instead), which keeps it short of a 5.

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