1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@kbask how does login retry work?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

kbask

by sughosh-pocketfm

Overview Schema Source Related Servers Discussions Admin

Python

Local

kbask

Hybrid MCP server that combines Graphify (structural code graphs) with Understand-Anything (LLM-derived semantic knowledge bases) into a single MCP endpoint.

Graphify tells you where things are. Understand-Anything tells you why they exist. kbask joins both and exposes them as MCP tools usable from Claude Code, Codex, Gemini CLI, and any other MCP-compatible host.

Why a hybrid?

Backend	Strength	Weakness
Graphify	Exact, cheap, deterministic AST graph (calls, imports, ownership)	No semantics — doesn't know why code exists
Understand-Anything	Semantic narrative, domain knowledge, onboarding context	Expensive to build, fuzzy, no edge-precise lookups

kbask gives you:

All 7 Graphify tools (query_graph, get_node, get_neighbors, get_community, god_nodes, graph_stats, shortest_path) pass-through
5 semantic tools from Understand-Anything (semantic_explain, semantic_chat, semantic_diff, semantic_onboard, semantic_domain)
Hybrid tools that compose both:
- ask(question) — structural BFS then semantic narrative on top candidates
- trace(from, to) — shortest path + per-hop semantic gloss
- onboard(area) — community detection + domain knowledge per cluster
reload(target?) — drop in-process caches so the next call re-reads kbask-out/ from disk (target=all|structural|semantic, default all)

If Understand-Anything is not built for the target repo, hybrid tools automatically degrade to a graphify-only mode. The response includes mode: "graphify-only", the structural bundle, file-candidate hints, and a prompt_hint that reframes the request (e.g. "with graphify mcp how does auth work?") so the calling LLM reasons from structural data + direct file reads instead of erroring on missing semantic context.

Related MCP server: CodeGraphMCPServer

Install

Latest release: 0.1.1 — assets: kbask-0.1.1-py3-none-any.whl, kbask-0.1.1.tar.gz, SHA256SUMS, install.sh, tool-install.sh.
Next release, 0.1.2: Hybrid tools (ask/trace/onboard) now auto-fall-back to a graphify-only mode when Understand-Anything is not built for the target repo — the response carries a prompt_hint that instructs the calling LLM to reason from structural data + direct file reads instead of erroring on missing semantic context.
Not yet on PyPI. Install from the GitHub Release, from main, or pinned to a tag. Once on PyPI, --from kbask resolves from there with no other change.

Releases are cut as X.Y.Z git tags (the leading v is optional — both 0.1.1 and v0.1.1 are accepted). The release GitHub Action builds a wheel + sdist, attaches them (and install.sh / tool-install.sh / SHA256SUMS) to the GitHub Release, and — if PYPI_TOKEN is configured — uploads the wheel to PyPI. See Releases for the cut process.

Pick the install style that matches your workflow:

A. Persistent CLI (`uv tool install`) — recommended

Puts kbask on your PATH so you can type it like any other tool:

# Latest release (auto-discovers GitHub Release wheel)
curl -fsSL https://raw.githubusercontent.com/sughosh-pocketfm/kbask/main/tool-install.sh | bash

# Pin to a specific release tag
KBASK_TAG=0.1.1 \
  curl -fsSL https://raw.githubusercontent.com/sughosh-pocketfm/kbask/main/tool-install.sh | bash

The script:

Installs uv if missing (Astral installer).
Hits https://api.github.com/repos/sughosh-pocketfm/kbask/releases/latest to find the wheel asset. Pin a release with KBASK_TAG=X.Y.Z (e.g. KBASK_TAG=0.1.1).
Falls back to git+https://github.com/sughosh-pocketfm/kbask if no release exists yet (or for main).
Runs uv tool install --force so kbask lands in ~/.local/bin.

After install:

kbask install claude --repo .     # wire MCP into Claude Code
kbask update .                    # build/refresh knowledge graph
kbask doctor                      # check dependencies
kbask --help

See Upgrade kbask for refresh commands.

After upgrading, restart your MCP host (Claude Code / Codex / Gemini) so it respawns kbask serve against the new binary.

B. One-shot host installer (no persistent CLI)

Wires kbask into a single MCP host's config without leaving a global kbask binary. The MCP server itself is spawned by the host via uvx --from git+... on demand.

curl -fsSL https://raw.githubusercontent.com/sughosh-pocketfm/kbask/main/install.sh | bash -s claude
# or: bash -s codex   |   bash -s gemini

# Pin to a tag (the MCP config gets the same pin):
KBASK_SOURCE="git+https://github.com/sughosh-pocketfm/kbask@0.1.1" \
  curl -fsSL https://raw.githubusercontent.com/sughosh-pocketfm/kbask/main/install.sh | bash -s claude

C. Direct uvx (no scripts)

# Latest main
uvx --from git+https://github.com/sughosh-pocketfm/kbask kbask install claude --repo .

# Pinned tag
uvx --from "git+https://github.com/sughosh-pocketfm/kbask@0.1.1" kbask install claude --repo .

# From a downloaded wheel (verify SHA256SUMS first)
uvx --from ./kbask-0.1.1-py3-none-any.whl kbask install claude --repo .

D. After PyPI publish

Everything above keeps working, plus:

uv tool install kbask                  # persistent CLI
uvx --from kbask kbask install claude  # one-shot
uvx kbask --help                       # script + pkg share name

Upgrade kbask

Match the path you installed with:

A. Persistent CLI (uv tool install)

# In-place refresh from the latest GitHub Release (verifies SHA256SUMS):
kbask update-bin
# Pin a specific tag:
kbask update-bin --tag 0.1.1
# Or use uv directly:
uv tool upgrade kbask
# Or rerun the curl one-liner (always uses --force):
curl -fsSL https://raw.githubusercontent.com/sughosh-pocketfm/kbask/main/tool-install.sh | bash
KBASK_TAG=0.1.1 curl -fsSL https://raw.githubusercontent.com/sughosh-pocketfm/kbask/main/tool-install.sh | bash

B/C. uvx ephemeral (hosts spawn it on demand)

uvx --from kbask kbask serve (or the git/wheel form) refetches per spawn. To force a fresh pull instead of the cached version:

uv cache clean kbask

Local wheel

uv tool install --force ./kbask-0.1.1-py3-none-any.whl

After upgrading, restart your MCP host (Claude Code / Codex / Gemini) so it respawns kbask serve against the new binary. Existing host sessions keep the old process until restart.

Verify a release artifact

# From the release page, grab SHA256SUMS + the wheel
shasum -a 256 -c SHA256SUMS

What the installer does

Creates <repo>/kbask-out/ if missing.
Appends kbask-out/ to <repo>/.gitignore.
Writes/upserts the host's MCP server config (timestamped backup of any existing file).
Writes a /kbask slash command for the host:
- Claude Code → <repo>/.claude/commands/kbask.md
- Codex CLI → ~/.codex/prompts/kbask.md
- Gemini CLI → ~/.gemini/commands/kbask.toml
- Pass --no-slash-command to skip.
Runs an MCP initialize + tools/list smoke test against the configured server.

After restart, you can invoke the slash command from chat: type /kbask how does X work? (or just /kbask to see its prompt).

Dependency preflight

Both kbask install <host> and kbask update print a status report for the upstreams kbask depends on:

[ok]   graphifyy ........... 0.5.0 (importable)
[ok]   graphify CLI ........ runnable (graphify or uvx on PATH)
[warn] understand-anything . knowledge graph not built yet
       To build:
         1. /plugin marketplace add Lum1104/Understand-Anything
         2. /plugin install understand-anything    (inside Claude Code)
         3. /understand                             (from this repo, in Claude Code)
         4. kbask update .

Run it standalone any time:

kbask doctor [path/to/repo]

graphifyy is a hard dep — installed transitively with kbask.
understand-anything is built by an LLM in Claude Code (no analyzer binary). Even Codex / Gemini users build the graph via Claude Code once, then kbask mirrors it.

Pin to a fork

KBASK_SOURCE=git+https://github.com/your-fork/kbask@v0.2.0 \
  uvx --from $KBASK_SOURCE kbask install claude --repo .

Build the knowledge base

After installing, build the input artifacts inside your project repo:

cd /path/to/your/project

# 1. Structural graph (Graphify)
uvx --from graphifyy graphify update .

# 2. Semantic graph (Understand-Anything) — built by an LLM in your host.
#    In Claude Code, run /understand once and let it populate
#    .understand-anything/knowledge-graph.json.

# 3. Mirror both into kbask-out/
uvx --from git+https://github.com/sughosh-pocketfm/kbask kbask update .

Produces kbask-out/:

kbask-out/
├── graph.json              # Graphify structural graph
├── knowledge-graph.json    # Understand-Anything semantic graph (mirrored)
├── knowledge-graph.meta.json
└── meta.json               # per-file hashes, versions, last-build timestamps

First run rebuilds everything. Subsequent kbask update runs are incremental — only files whose content hash changed are re-analysed. Token cost scales with diff size, not repo size.

Use it from your agent

After restart, any MCP-compatible host can call:

kbask.ask("how does login retry work?")
kbask.trace("LoginViewModel", "AuthRepository")
kbask.query_graph("ExoPlayer initialisation")
kbask.semantic_explain("aural/player/data/.../PlayerManager.kt")

Incremental updates

kbask update is a single command. There is no --structural / --semantic split — kbask figures out what changed and only regenerates the missing slice:

kbask update .
├── 1. Run Graphify → new graph.json
├── 2. Diff per-file content hashes against meta.json
│      → dirty = added | modified
│      → preserved = unchanged
│      → removed = deleted from repo
├── 3. Mirror <repo>/.understand-anything/knowledge-graph.json → kbask-out/
├── 4. Carry forward unchanged file entries; mark dirty/removed in meta.json
└── 5. Write meta.json (new hashes, timestamps, versions)

Note on the semantic graph. Understand-Anything has no self-running analyzer — its knowledge graph is built by an LLM (Claude Code) following the upstream plugin's prompts and persisted to <repo>/.understand-anything/knowledge-graph.json. kbask update mirrors that file into kbask-out/; rebuilding the upstream graph is owned by the LLM (e.g. /understand-update in Claude Code). If <repo>/.understand-anything/ is absent, semantic tools still report a clean "not built" error and structural tools keep working.

Flags:

kbask update . — incremental (default)
kbask update . --force — full rebuild, ignore meta.json
kbask update . --dry-run — print planned work, no writes
kbask update . --structural-only — Graphify only, skip semantic mirror

Host setup

kbask follows the MCP spec strictly (JSON-RPC 2.0 over stdio, standard tool schemas). It works in any host that speaks MCP.

Claude Code

Project-scope .mcp.json at your repo root:

{
  "mcpServers": {
    "kbask": {
      "type": "stdio",
      "command": "uvx",
      "args": [
        "--from", "git+https://github.com/sughosh-pocketfm/kbask",
        "--with", "mcp",
        "kbask", "serve", "kbask-out/"
      ]
    }
  }
}

After PyPI publish, replace "git+https://github.com/sughosh-pocketfm/kbask" with "kbask".

Or run the installer:

uvx --from git+https://github.com/sughosh-pocketfm/kbask kbask install claude --repo .

Codex CLI

Writes to $CODEX_HOME/config.toml (default ~/.codex/config.toml):

[mcp_servers.kbask]
args = ["--from", "git+https://github.com/sughosh-pocketfm/kbask", "--with", "mcp", "kbask", "serve", "/absolute/path/to/kbask-out"]
command = "uvx"
startup_timeout_sec = 120

uvx --from git+https://github.com/sughosh-pocketfm/kbask kbask install codex --repo .

Gemini CLI

Writes mcpServers block into ~/.gemini/settings.json:

{
  "mcpServers": {
    "kbask": {
      "command": "uvx",
      "args": [
        "--from", "git+https://github.com/sughosh-pocketfm/kbask",
        "--with", "mcp",
        "kbask", "serve", "/absolute/path/to/kbask-out"
      ]
    }
  }
}

uvx --from git+https://github.com/sughosh-pocketfm/kbask kbask install gemini --repo .

AGY

Status: not yet supported. Config path / format for AGY hosts is not documented here. Open an issue if you need it — installer template is one file (scripts/install-agy.py) once the path is confirmed.

Other MCP hosts

kbask serve <kbask-out-dir> speaks stdio MCP. Wire it the same way as any stdio MCP server in your host of choice.

Tool catalogue

Tool	Source	Description
`query_graph`	structural	BFS/DFS keyword search over the code graph
`get_node`	structural	Look up a single node by label/ID
`get_neighbors`	structural	First-hop neighbors of a node
`get_community`	structural	Members of a Louvain community
`god_nodes`	structural	Highest-centrality nodes (hot spots)
`graph_stats`	structural	Graph counts, density, top communities
`shortest_path`	structural	Path between two nodes
`semantic_explain`	semantic	Narrative explanation of a file or symbol
`semantic_chat`	semantic	Free-form question against the knowledge graph
`semantic_diff`	semantic	Explain what a git diff changes and why
`semantic_onboard`	semantic	Onboarding guide for a module
`semantic_domain`	semantic	Business-domain mapping for an area
`ask`	hybrid	Structural candidates + semantic narrative in one call
`trace`	hybrid	Shortest path with semantic gloss per hop
`onboard`	hybrid	Community clusters + domain knowledge per cluster
`reload`	admin	Drop in-process caches; next call re-reads `kbask-out/` from disk (`target=all\|structural\|semantic`)

All tools return structured JSON. None of them call an LLM internally — they return context bundles for the calling agent's LLM to reason over. This mirrors Graphify's token_budget discipline and keeps the MCP host-agnostic.

Token accounting

Every tool response carries a _meta block reporting the approximate token + byte cost of that single call:

{
  "...your tool payload...": "...",
  "_meta": {
    "tool": "query_graph",
    "tokens": {"input": 12, "output": 1843, "total": 1855},
    "bytes":  {"input": 47, "output": 7321},
    "encoder": "heuristic:chars/4"
  }
}

By default kbask uses a len(text) / 4 heuristic (good to ~10%). For tokenizer-accurate counts install the optional extra:

uv pip install 'kbask[tokens]'    # or: pip install 'kbask[tokens]'

That swaps the encoder to tiktoken:cl100k_base. The agent can read _meta.tokens.total per call and self-throttle (e.g. drop depth or token_budget if a sweep is going hot).

Architecture

kbask (Python, stdio MCP)
├── backends/
│   ├── graphify.py        # reuses graphify.serve internals via networkx (no subprocess)
│   └── understand.py      # reads <repo>/.understand-anything/knowledge-graph.json
├── tools/
│   ├── structural.py      # 7 pass-through wrappers around graphify
│   ├── semantic.py        # 5 wrappers reading the mirrored knowledge graph
│   └── hybrid.py          # ask / trace / onboard — compose both backends
├── installers/            # per-host config writers (Claude / Codex / Gemini / AGY)
├── update.py              # incremental orchestrator (hash diff + mirror)
├── diff.py                # per-file hash delta
├── meta.py                # meta.json IO + hash_file
├── state.py               # process-wide out_dir holder
└── serve.py               # MCP stdio entry point — registers 16 tools

Design rules:

Don't fork upstreams. Graphify and Understand-Anything are pinned dependencies, never patched.
Schemas stay separate. Cross-reference by (file_path, line) — the only stable join key between the two graphs.
stdout is sacred. All logs to stderr. stdout is reserved for JSON-RPC frames.
No host detection. Server behaves identically regardless of caller. No Claude-isms.
No auto-rebuild. Host decides when to refresh — no file watchers, no background work.

Releases

Versioning

v<MAJOR>.<MINOR>.<PATCH> (SemVer). Pre-1.0 — breaking changes can land on any minor bump.

The release tag is the source of truth. The release workflow strips an optional leading v, writes that version into pyproject.toml and src/kbask/__init__.py before building, and then commits the same version bump back to main if needed.

Cutting a release

# Tag the commit you want to release; both styles are accepted.
git tag 0.1.1
git push origin main --tags

Manual run (e.g. to re-cut from a fixed branch) is also supported:

gh workflow run release.yml -f tag=0.1.1

What the release pipeline does

.github/workflows/release.yml on tag push:

Checks out at the tag.
Sets up uv and Python 3.11.
Resolves the version from the tag and writes it into source files.
uv build → dist/kbask-X.Y.Z-py3-none-any.whl and dist/kbask-X.Y.Z.tar.gz.
Smoke-tests the wheel — pip install + kbask --help must succeed.
Generates SHA256SUMS.
Creates the GitHub Release with auto-generated changelog and the following assets attached:
- kbask-X.Y.Z-py3-none-any.whl
- kbask-X.Y.Z.tar.gz
- SHA256SUMS
- install.sh (one-shot host installer bootstrap)
- tool-install.sh (uv tool install bootstrap)
Publishes to PyPI only if the PYPI_TOKEN repo secret is configured.
Commits chore(release): bump version to X.Y.Z [skip ci] back to main when main does not already contain that version.

Required repo secrets

Secret	Purpose	Optional?
`PYPI_TOKEN`	`uv publish` API token	Yes — release runs without it; only PyPI step is skipped.

GITHUB_TOKEN is provided automatically (used by softprops/action-gh-release for the Release write).

Consumer install paths after release

Once the release exists:

# A. Persistent CLI — auto-finds the wheel
curl -fsSL https://raw.githubusercontent.com/sughosh-pocketfm/kbask/main/tool-install.sh | bash

# B. Pinned tag
KBASK_TAG=0.1.1 curl -fsSL https://raw.githubusercontent.com/sughosh-pocketfm/kbask/main/tool-install.sh | bash

# C. Direct download
gh release download 0.1.1 --repo sughosh-pocketfm/kbask --pattern '*.whl'
shasum -a 256 -c SHA256SUMS
uv tool install ./kbask-0.1.1-py3-none-any.whl

tool-install.sh hits GET /repos/{owner}/{repo}/releases/latest to discover the newest tag and prefers the wheel asset over the git source.

Status

Capability	State
MCP stdio server + 16 tools	✅
Structural tools via `graphify.serve` internals	✅
Semantic tools reading mirrored knowledge graph	✅
Hybrid `ask` / `trace` / `onboard` (3-stage cascade)	✅
Incremental `kbask update`	✅ structural rebuild + semantic mirror
Per-tool `_meta.tokens` accounting	✅ heuristic; `kbask[tokens]` extra for tiktoken
Tolerant node lookup (path / basename / label / id)	✅
Dependency preflight (`kbask doctor`)	✅
`/kbask` slash command writer (Claude/Codex/Gemini)	✅
Installer scripts (Claude/Codex/Gemini)	✅
`tool-install.sh` + `install.sh` curl bootstraps	✅
GitHub Release pipeline (wheel/sdist/checksums)	✅
PyPI publish	⏳ token not yet configured
AGY installer	⏳ blocked on config-path docs

This is an alpha MVP. APIs may change.

Development

git clone https://github.com/sughosh-pocketfm/kbask.git
cd kbask
uv venv && source .venv/bin/activate
uv pip install -e ".[dev]"
pytest

License

MIT — see LICENSE.

Built on top of graphifyy and @understand-anything/core. Their licenses apply to their respective components.

Available Tools

10 tools

get_communityC

Get all nodes in a community by community ID.

ParametersJSON Schema

Name	Required	Description	Default
`community_id`	Yes	Community ID (0-indexed by size)
`project_path`	No	Absolute path to a project directory containing graphify-out/graph.json. Optional — defaults to the graph this server was started with.

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are present, so the description must convey behavioral traits. It only states what the tool returns ('all nodes'), with no mention of read-only nature, potential errors, side effects, or performance implications.

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?

The description is a single, straightforward sentence with no unnecessary words. It is concise, though it could benefit from more structure or bullet points for additional details.

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

Completeness2/5

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

Given the absence of an output schema and annotations, the description is too sparse. It does not clarify what information about the nodes is returned, nor does it address pagination or error scenarios.

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 coverage is 100% with each parameter having a clear description. The tool's description adds no extra meaning beyond the schema, but the schema itself is sufficient. Baseline 3 is appropriate.

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 clearly states the action ('get'), the resource ('all nodes in a community'), and the key identifier ('by community ID'). It is specific enough to distinguish from sibling tools like get_node or get_neighbors, though it does not explicitly differentiate them.

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?

No guidance is provided on when to use this tool versus alternatives, nor are there any conditions or prerequisites mentioned. The description does not cover when not to use it.

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

get_neighborsA

Get all direct neighbors of a node with edge details.

ParametersJSON Schema

Name	Required	Description
`label`	Yes
`project_path`	No	Absolute path to a project directory containing graphify-out/graph.json. Optional — defaults to the graph this server was started with.
`relation_filter`	No	Optional: filter by relation type

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations, the description should disclose behavioral traits. It mentions 'edge details' but does not specify what details (e.g., direction, properties), nor does it mention pagination, performance, or resource impact. This is minimal disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Single sentence of 9 words. No filler, front-loaded. Every word adds value.

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?

Given no output schema and no annotations, the description is adequate for a simple neighbor lookup but lacks details on output structure (node vs edge format, order). It covers basic functionality.

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 coverage is 67% (2 of 3 params described). The description adds no extra meaning to any parameter; the undocument label param is not explained. Baseline 3 is appropriate as schema already provides most info.

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 'Get all direct neighbors of a node with edge details' clearly states the action (get), the resource (direct neighbors), and distinguishes from siblings like get_node (single node) and shortest_path (paths).

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 implies usage when direct neighbors with edge details are needed, but no explicit guidance on when not to use or alternatives. Sibling tools like get_node or shortest_path are not referenced.

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

get_nodeB

Get full details for a specific node by label or ID.

ParametersJSON Schema

Name	Required	Description	Default
`label`	Yes	Node label or ID to look up
`project_path`	No	Absolute path to a project directory containing graphify-out/graph.json. Optional — defaults to the graph this server was started with.

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, and the description does not disclose any behavioral traits (e.g., read-only nature, potential errors, or data freshness). Merely states 'get full details' without elaboration.

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?

Single sentence with no unnecessary words, though could be slightly more informative without losing efficiency.

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?

Tool is simple with two parameters and no output schema; description omits what 'full details' includes, and no return value is specified, leaving some ambiguity for an AI agent.

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 coverage is 100%, so description adds minimal value beyond the schema's parameter descriptions (e.g., 'by label or ID' is already in schema). Baseline 3 is appropriate.

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?

Description clearly states the tool retrieves full details for a specific node by label or ID, a specific verb-resource pair that distinguishes it from sibling tools focused on communities, stats, or paths.

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?

No guidance on when to use this tool versus alternatives like get_community or get_neighbors, nor any exclusion criteria or prerequisites.

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

get_pr_impactA

Get detailed graph impact for a specific PR: which files it changes, which knowledge-graph communities are affected, and how many nodes are touched. Use this to assess merge risk or check for overlap with your current work.

ParametersJSON Schema

Name	Required	Description
`repo`	No	GitHub repo (owner/repo). Defaults to current repo.
`pr_number`	Yes	PR number to analyse
`project_path`	No	Absolute path to a project directory containing graphify-out/graph.json. Optional — defaults to the graph this server was started with.

TDQS

A3.8/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It describes the tool's function but does not disclose side effects, rate limits, or whether it is read-only. More behavioral context needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Two sentences, front-loaded with key information. No wasted words, efficient and clear.

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?

Given no output schema and 3 parameters, description covers main output aspects (files, communities, nodes). Could benefit from more detail on return format, but sufficient for core purpose.

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 coverage is 100%, so baseline 3. Description does not add extra meaning to parameters beyond what schema already provides. No additional detail on defaults or usage.

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 clearly states the tool gets detailed graph impact for a specific PR, listing what it provides (files changed, communities affected, nodes touched). It distinguishes from siblings by focusing on PR impact rather than general graph queries.

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?

Explicitly states 'Use this to assess merge risk or check for overlap with your current work,' giving clear context. Does not explicitly mention when not to use, but siblings provide alternatives.

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

god_nodesB

Return the most connected nodes - the core abstractions of the knowledge graph.

ParametersJSON Schema

Name	Required	Description	Default
`top_n`	No
`project_path`	No	Absolute path to a project directory containing graphify-out/graph.json. Optional — defaults to the graph this server was started with.

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description must disclose behavior but only states the return type. It does not explain how 'most connected' is determined, sorting order, or any side effects. For a read operation, minimal behavioral info is provided.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

A single sentence with 12 words, efficiently conveying the core purpose. It is front-loaded and contains no redundant information.

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

Completeness2/5

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

Given the lack of output schema and annotations, the description is incomplete. It omits details on connectivity metric, error cases, and proper use of parameters, leaving the agent insufficiently informed.

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

Parameters2/5

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

Schema coverage is 50% (only 'project_path' has a description). The tool description does not help explain 'top_n' beyond its default value, failing to compensate for the missing schema documentation.

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 clearly states the verb 'Return' and the resource 'most connected nodes', with context as 'core abstractions of the knowledge graph'. It distinguishes this tool from sibling tools like 'get_node' or 'get_neighbors' by focusing on connectivity abstraction.

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?

No guidance is provided on when to use this tool versus alternatives such as 'get_community' or 'graph_stats'. The description implies usage but lacks explicit context or exclusions.

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

graph_statsA

Return summary statistics: node count, edge count, communities, confidence breakdown.

ParametersJSON Schema

Name	Required	Description	Default
`project_path`	No	Absolute path to a project directory containing graphify-out/graph.json. Optional — defaults to the graph this server was started with.

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It states it returns read-only summary statistics, but lacks details on performance (e.g., costly for large graphs), side effects, or prerequisites (e.g., graph must be loaded). This is insufficient for a tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is a single sentence that is concise and front-loaded with the verb 'return'. Every word adds value, no filler or redundancy.

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?

Given no output schema and no annotations, the description lists four return fields but omits details like data format, ordering, or whether the confidence breakdown is per community or overall. It is minimally complete but could be richer.

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 coverage is 100% and the parameter 'project_path' is well-described in the schema. The tool description adds no additional semantic meaning beyond the schema, but since the schema already covers it, a baseline score of 3 is appropriate.

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?

Description uses verb 'return' and lists specific items (node count, edge count, communities, confidence breakdown), clearly distinguishing it from siblings like 'get_community' (returns a specific community) or 'shortest_path' (pathfinding). It precisely states the tool's purpose.

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 provides no guidance on when to use this tool vs alternatives (e.g., 'get_community' for a specific community). It is implied that for summary statistics one uses this tool, but explicit when-to-use or when-not-to-use is missing.

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

list_prsA

List open GitHub PRs with CI status, review state, and graph impact (which communities each PR touches, blast radius). Use this before starting work to check if a PR already covers the area you're about to change.

ParametersJSON Schema

Name	Required	Description
`base`	No	Base branch to filter PRs by (auto-detected if omitted)
`repo`	No	GitHub repo (owner/repo). Defaults to current repo.
`project_path`	No	Absolute path to a project directory containing graphify-out/graph.json. Optional — defaults to the graph this server was started with.

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. Mentions the data returned (CI status, review state, graph impact) but does not state that it is a read-only operation or disclose any side effects, auth requirements, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Two sentences with no waste. First sentence clearly states purpose and outputs; second sentence gives usage context. Front-loaded and efficient.

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?

Given no output schema and no annotations, description provides a reasonable overview. However, it lacks explanation of the output structure for 'graph impact' and does not specify pagination or filtering beyond parameters. Adequate but could be more complete.

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 baseline is 3. Description adds minimal value beyond schema descriptions; it does not provide additional parameter details like default behavior for omitted parameters or format expectations.

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?

Description explicitly states the tool lists open GitHub PRs with CI status, review state, and graph impact. Action verb 'List' and specific resource 'open GitHub PRs' along with key data points, distinguishing it from siblings like get_pr_impact and triage_prs.

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?

Provides explicit usage context: 'Use this before starting work to check if a PR already covers the area you're about to change.' Does not explicitly mention when not to use or list alternatives, but the guidance is clear and actionable.

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

query_graphB

Search the knowledge graph using BFS or DFS. Returns relevant nodes and edges as text context.

ParametersJSON Schema

Name	Required	Description	Default
`mode`	No	bfs=broad context, dfs=trace a specific path	bfs
`depth`	No	Traversal depth (1-6)
`question`	Yes	Natural language question or keyword search
`project_path`	No	Absolute path to a project directory containing graphify-out/graph.json. Optional — defaults to the graph this server was started with.
`token_budget`	No	Max output tokens
`context_filter`	No	Optional explicit edge-context filter, e.g. ['call', 'field']

TDQS

B3.4/5.0

Behavior3/5

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

No annotations provided, so the description must carry the burden. It states the tool returns 'relevant nodes and edges as text context' but does not explain output structure, side effects, or required permissions. The description adds limited behavioral context beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The description is a single sentence, which is concise but too brief for a 6-parameter tool. It front-loads the main purpose but omits important details, making it borderline underspecified.

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

Completeness2/5

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

Given the tool's complexity (6 params, no output schema, no annotations) and multiple siblings, the description is incomplete. It does not explain what 'text context' looks like, how to interpret results, or provide usage examples. Sibling tools like graph_stats are not differentiated.

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 baseline is 3. The tool description adds no extra meaning over the schema; it repeats the mode choices but without enriching parameter semantics.

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 clearly states the tool searches a knowledge graph using BFS or DFS, distinguishing it from siblings like get_node (single node retrieval) and shortest_path (path-specific). The verb 'Search' and resource 'knowledge graph' are specific.

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?

No explicit guidance on when to use BFS vs DFS, nor compared to alternative tools like get_neighbors or shortest_path. The description implies use for traversal but lacks contextual decision rules.

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

shortest_pathC

Find the shortest path between two concepts in the knowledge graph.

ParametersJSON Schema

Name	Required	Description
`source`	Yes	Source concept label or keyword
`target`	Yes	Target concept label or keyword
`max_hops`	No	Maximum hops to consider
`project_path`	No	Absolute path to a project directory containing graphify-out/graph.json. Optional — defaults to the graph this server was started with.

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so the description must carry the full burden. It only states the high-level function without disclosing algorithm complexity, output format, error handling (e.g., no path found), or other behavioral traits.

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?

Single sentence, no extraneous words. However, it lacks structure such as bullet points or separated sections; the minimalism is acceptable but not exemplary.

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

Completeness2/5

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

Given no annotations or output schema, the description should explain what 'concepts' are, what the output looks like, and limitations. It fails to provide enough context for an agent to fully understand the tool's behavior.

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 covers all 4 parameters with descriptions, so description adds no extra meaning beyond the schema. Baseline 3 is appropriate.

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 states the action (find) and resource (shortest path) clearly, specifying it operates on two concepts in the knowledge graph. It distinguishes from sibling tools like get_node or get_neighbors but does not explicitly differentiate itself.

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?

No guidance on when to use this tool versus alternatives like query_graph or get_neighbors. No prerequisites or exclusions mentioned.

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

triage_prsA

Return all actionable open PRs (correct base, not stale) with full graph impact data so you can reason about review priority, merge order, and conflict risk. Call this when the user asks 'what PRs should I review?' or 'what's ready to merge?'

ParametersJSON Schema

Name	Required	Description
`base`	No	Base branch to filter PRs by (auto-detected if omitted)
`repo`	No	GitHub repo (owner/repo). Defaults to current repo.
`project_path`	No	Absolute path to a project directory containing graphify-out/graph.json. Optional — defaults to the graph this server was started with.

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It explains the filtering criteria (correct base, not stale) and mentions graph impact data. However, it doesn't define 'actionable' or 'stale' precisely, nor does it disclose any side effects, rate limits, or output structure details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description consists of two sentences: first sentence states purpose and value, second sentence gives usage guidance. It is front-loaded, concise, and contains no filler.

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?

The description lacks output schema, so it should provide more detail on the return value. While it mentions 'full graph impact data' and reasoning use cases, it does not specify the structure or fields included, leaving the agent partially informed.

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 coverage is 100%, so the schema already describes all three parameters (base, repo, project_path) with clear defaults. The tool description does not add additional parameter-level semantics beyond what the schema provides.

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 uses specific verbs ('return') and a clear resource ('actionable open PRs with graph impact data'). It distinguishes from sibling tools like list_prs (raw list) and get_pr_impact (single PR) by emphasizing triage and priority reasoning.

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?

The description explicitly states when to call the tool ('when user asks what PRs to review or what's ready to merge'). It provides clear context but does not explicitly mention when not to use it or which sibling alternatives to choose.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

10 tool updatesv0.1.2Jul 6, 2026
- First observedget_community
- First observedget_neighbors
- First observedget_node
- First observedget_pr_impact
- First observedgod_nodes
- First observedgraph_stats
- First observedlist_prs
- First observedquery_graph
- First observedshortest_path
- First observedtriage_prs

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-07-06 07:50 across 10 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: nodes, communities, paths, PRs, and stats. Even PR-related tools (list_prs, triage_prs, get_pr_impact) have well-differentiated roles. No ambiguity in selecting the correct tool.

Naming Consistency4/5

Most tools use snake_case verb_noun (get_community, list_prs, triage_prs). Two tools (god_nodes, graph_stats) are noun_noun, but still predictable. Overall pattern is clear and easy to follow.

Tool Count5/5

10 tools is well-scoped for a knowledge base query and PR analysis server. Each tool serves a specific purpose without redundancy or overwhelming the agent.

Completeness4/5

Covers core query operations (node, community, path, search) and PR impact analysis. Missing CRUD operations for nodes, but the domain appears focused on read-only exploration, so gaps are minor.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Meeba Brain A
io.github.meemoprasad
Repository knowledge graph MCP server for codebase understanding and debugging.
Code Analysis Developer Tools
51
gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5364
strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102

Related MCP Servers

nexus-mcp-ci
AI & Machine Learning Code Analysis Developer Tools
jaggernaut007
A
license
A
quality
B
maintenance
Unified MCP server: hybrid search + code graph + semantic memory. 10 tools, <350MB RAM, fully local. No API keys.
Updated 4 days ago (2026-09-18 15:37 UTC)
10
PolyForm Noncommercial 1.0.0
CodeGraphMCPServer
Code Analysis RAG Systems Developer Tools
nahisaho
A
license
Not graded
quality
D
maintenance
A lightweight, zero-configuration MCP server for source code analysis with GraphRAG capabilities, enabling structural understanding and efficient code completion from MCP-compatible AI tools.
Updated 9 months ago (2025-12-11 12:55 UTC)
32 PyPI
12
MIT
GraphRagMCP V2
dejavuxerss
-
license
Not graded
quality
Not graded
maintenance
An advanced MCP server that provides deep code understanding and analysis using GraphRAG, AST parsing, and semantic memory, enabling AI agents to query and interact with complex codebases.
Updated 3 months ago (2026-06-08 18:00 UTC)
-
graphify-mcp
Knowledge & Memory Developer Tools Code Analysis
yasinyaman
A
license
A
quality
B
maintenance
A Python MCP server that exposes the Graphify knowledge graph as MCP tools, prompts, and resources, enabling AI assistants to explore codebases through a token-budgeted, structural graph during development.
Updated 23 days ago (2026-08-30 13:13 UTC)
16
3
MIT

kbask

Why a hybrid?

Install

A. Persistent CLI (uv tool install) — recommended

B. One-shot host installer (no persistent CLI)

C. Direct uvx (no scripts)

D. After PyPI publish

Upgrade kbask

Verify a release artifact

What the installer does

Dependency preflight

Pin to a fork

Build the knowledge base

Use it from your agent

Incremental updates

Host setup

Claude Code

Codex CLI

Gemini CLI

AGY

Other MCP hosts

Tool catalogue

Token accounting

Architecture

Releases

Versioning

Cutting a release

What the release pipeline does

Required repo secrets

Consumer install paths after release

Status

Development

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

A. Persistent CLI (`uv tool install`) — recommended