Skip to main content
Glama
Filmystar

LightRAG Code Brain MCP

by Filmystar
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

LightRAG Code Brain MCP

LightRAG Code Brain MCP turns a local LightRAG server into a persistent project brain for coding agents such as Claude Code and Codex.

It provides:

  • whole-codebase indexing with conservative default excludes and secret redaction

  • multi-repo source names with repo_id:relative/path

  • RAG query/context/data tools

  • durable memory across sessions

  • senior-developer project profile sections

  • a task gate that encourages agents to load/update memory for non-trivial work

What This Solves

Coding agents often reread the same files, forget prior fixes, and lose setup history between sessions. This MCP gives them a durable memory layer:

  • architecture and module boundaries

  • conventions, workflows, and hazards

  • debugging playbooks and failed attempts

  • setup outcomes and provider quirks

  • current project profile and handoff notes

It does not replace reading source files for exact edits. It reduces discovery tokens and gives the agent a senior-engineer orientation before it opens files.

Related MCP server: lens

Requirements

  • Docker with Compose

  • Python 3.10+

  • A chat/LLM provider compatible with OpenAI chat completions

  • An embeddings provider compatible with OpenAI /v1/embeddings

  • Claude Code and/or Codex if you want agent integration

Quick Start

git clone https://github.com/YOUR_ORG/lightrag-code-brain-mcp.git
cd lightrag-code-brain-mcp
cp .env.example .env

Edit .env:

LIGHTRAG_AUTH_ACCOUNTS="admin:your-password"
LIGHTRAG_USERNAME="admin"
LIGHTRAG_PASSWORD="your-password"
LIGHTRAG_TOKEN_SECRET="a-long-random-string"

LIGHTRAG_LLM_BINDING_HOST="https://api.openai.com/v1"
LIGHTRAG_LLM_API_KEY="..."
LIGHTRAG_LLM_MODEL="gpt-4o-mini"

LIGHTRAG_EMBEDDING_BINDING_HOST="https://api.openai.com/v1"
LIGHTRAG_EMBEDDING_API_KEY="..."
LIGHTRAG_EMBEDDING_MODEL="text-embedding-3-large"
LIGHTRAG_EMBEDDING_DIM="3072"

Start LightRAG:

docker compose up -d
curl http://127.0.0.1:9621/health

NVIDIA NIM Embeddings

If you use NVIDIA NIM, this model worked with LightRAG's OpenAI-compatible embedding call because it does not require input_type:

LIGHTRAG_EMBEDDING_BINDING_HOST="https://integrate.api.nvidia.com/v1"
LIGHTRAG_EMBEDDING_API_KEY="nvapi-..."
LIGHTRAG_EMBEDDING_MODEL="nvidia/nv-embed-v1"
LIGHTRAG_EMBEDDING_DIM="4096"

Some NVIDIA embedding models require input_type; those may fail through LightRAG's default OpenAI embedding request.

Install In Codex

export LIGHTRAG_URL="http://127.0.0.1:9621"
export LIGHTRAG_USERNAME="admin"
export LIGHTRAG_PASSWORD="your-password"
export LIGHTRAG_DEFAULT_REPO_ROOT="/path/to/your/project"
export LIGHTRAG_DEFAULT_REPO_ID="my-project"
./install-codex.sh
codex mcp list

This runs:

codex mcp add lightrag-code-brain \
  --env LIGHTRAG_URL=http://127.0.0.1:9621 \
  --env LIGHTRAG_USERNAME=admin \
  --env LIGHTRAG_PASSWORD=your-password \
  --env LIGHTRAG_DEFAULT_REPO_ROOT=/path/to/your/project \
  --env LIGHTRAG_DEFAULT_REPO_ID=my-project \
  -- python /absolute/path/lightrag_mcp_server.py

Install In Claude Code

export LIGHTRAG_URL="http://127.0.0.1:9621"
export LIGHTRAG_USERNAME="admin"
export LIGHTRAG_PASSWORD="your-password"
export LIGHTRAG_DEFAULT_REPO_ROOT="/path/to/your/project"
export LIGHTRAG_DEFAULT_REPO_ID="my-project"
./install-claude.sh

Copy the generated .mcp.json into your Claude Code project root, or merge the mcpServers entry into an existing .mcp.json.

Examples are also provided in examples/:

  • examples/claude-mcp.json

  • examples/codex-install.sh

  • examples/AGENTS-snippet.md

Recommended Agent Instructions

Add this to your project CLAUDE.md, AGENTS.md, or equivalent:

Use the LightRAG MCP server as persistent project memory.

For non-trivial implementation/debugging/setup work:
- call `brain_begin` first
- use `senior_brief` for architecture/conventions/hazards
- use `brain_search` for prior fixes/failures when something is broken
- use `rag_index_repo` for whole-codebase indexing when needed
- after meaningful work, call `brain_remember`
- call `profile_upsert` when architecture/conventions/workflows/hazards change
- call `brain_finish` before final response

Tool Overview

RAG tools:

  • rag_ask

  • rag_get_context

  • rag_query_data

  • rag_status

  • rag_clear

  • rag_index_repo

  • rag_list_documents

  • rag_track_status

  • rag_reprocess_failed

  • rag_cancel_pipeline

  • rag_webui

Memory tools:

  • brain_remember

  • brain_search

  • brain_recent

  • brain_reindex

  • brain_begin

  • brain_finish

  • brain_gate_status

Senior project profile tools:

  • profile_bootstrap

  • profile_get

  • profile_upsert

  • profile_search

  • senior_brief

Whole-Codebase Indexing

Use rag_index_repo:

{
  "root": "/path/to/project",
  "repo_id": "my-project",
  "dry_run": true,
  "limit": 1000
}

Then run without dry_run.

Defaults intentionally skip:

  • .env, MCP config, local memory files

  • .git, .venv, caches, logs, lockfiles

  • node_modules, build/dist output

  • LightRAG storage and generated data

  • backup/temp/database/log files

  • files larger than 256 KiB

Secret-looking values are redacted before indexing.

Multi-Repo Support

Pass a stable repo_id for each repository:

{
  "root": "/work/project-a",
  "repo_id": "project-a"
}

Documents are indexed as:

project-a:relative/path.py

This keeps references distinguishable across repositories.

Publish Your Own Copy

git init
git add .
git commit -m "Initial LightRAG Code Brain MCP"
gh repo create lightrag-code-brain-mcp --public --source=. --remote=origin --push

Before publishing, confirm .env is not staged:

git status --short

Troubleshooting

Check LightRAG:

docker compose ps
docker compose logs --tail=100 lightrag
curl http://127.0.0.1:9621/health

Common issues:

  • 401: wrong LIGHTRAG_USERNAME / LIGHTRAG_PASSWORD

  • embedding 404: provider does not expose /v1/embeddings

  • NVIDIA input_type required: use nvidia/nv-embed-v1 or another compatible model

  • no context after indexing: wait for pipeline completion, then check rag_status

Security Notes

  • Do not commit .env.

  • Keep LightRAG bound to 127.0.0.1 unless you know what you are doing.

  • Rotate credentials if you accidentally indexed secrets before redaction.

  • Review rag_index_repo dry-run output before first full indexing.

Available Tools

23 tools
brain_beginB

Start the mandatory project-brain workflow for a non-trivial task. Creates a local gate file and optionally runs senior_brief immediately.

ParametersJSON Schema
NameRequiredDescriptionDefault
taskYes
repo_idNorepo1
senior_brief_requiredNo
brain_search_requiredNo
memory_update_requiredNo

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 fully disclose behaviors. It mentions creating a local gate file and optionally running senior_brief, but lacks details on idempotency, error states, permission requirements, or consequences of multiple calls.

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 the core purpose. No fluff, every word earns its place.

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 output schema and 5 undocumented parameters, the description is insufficient. It lacks return value info and per-parameter guidance, which are critical for correct usage.

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

Parameters1/5

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

The description does not explain any of the 5 parameters. Schema coverage is 0%, so the description adds no meaning beyond parameter names like 'task', 'repo_id', etc.

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 it starts a mandatory workflow for non-trivial tasks, creating a gate file. The verb 'start' and resource 'project-brain workflow' are specific. There are no other 'begin' siblings, so it distinguishes well.

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 indicates it's for 'non-trivial tasks' and optionally runs senior_brief, giving some context. However, it doesn't explicitly state when not to use this tool or provide alternatives like brain_finish for completion.

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

brain_finishC

Finish the mandatory project-brain workflow and record whether memory/profile updates were made before final response.

ParametersJSON Schema
NameRequiredDescriptionDefault
memory_idsNo
profile_updatedNo
brain_search_doneNo
noteNo

TDQS

C2.4/5.0
Behavior2/5

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

With no annotations, the description carries full burden. It mentions recording updates but does not disclose side effects (e.g., workflow finalization, irreversible actions) or auth requirements. The behavioral impact is only vaguely implied.

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 efficient sentence that immediately conveys the core purpose. It is well front-loaded, though it could include a bit more detail without becoming verbose.

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

Completeness1/5

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

Given 0% schema coverage, no output schema, and four parameters, the description is severely incomplete. It fails to explain parameters or what 'finish' entails, leaving the agent with insufficient information to use the tool correctly.

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

Parameters1/5

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

Schema description coverage is 0%, and the description adds no meaning to the four parameters. It only vaguely references recording updates but does not explain memory_ids, profile_updated, brain_search_done, or note.

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 tool finishes the mandatory project-brain workflow and records memory/profile updates, which distinguishes it from siblings like brain_begin or brain_search. However, it could be more specific about the workflow context.

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?

The description implies usage at the end of the project-brain workflow but provides no explicit when-to-use, when-not-to-use, or alternatives. There is no guidance on prerequisites or context.

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

brain_gate_statusB

Check whether the mandatory project-brain workflow gate is satisfied.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.4/5.0
Behavior2/5

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

No annotations exist, so the description carries full burden. It does not disclose whether the tool has side effects, what it returns, or if it is idempotent. For a status-checking tool, read-only behavior should be explicit.

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 with no extraneous information. It is front-loaded and efficiently conveys purpose.

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?

The description lacks explanation of what 'gate' refers to, what 'satisfied' means, and what the output looks like. For an agent to correctly interpret and act on the result, more context is needed.

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?

With zero parameters and 100% schema coverage (trivially), the description need not elaborate on parameters. Baseline score of 4 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?

The description clearly states the action ('Check') and the resource ('mandatory project-brain workflow gate'). It distinguishes from siblings like 'brain_begin' and 'brain_finish' which are different actions (start/finish vs. check status).

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, such as when to check gate status versus performing the gate action (begin/finish). The description does not provide context for appropriate invocation.

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

brain_recentC

List recent durable project memories from the local memory log.

ParametersJSON Schema
NameRequiredDescriptionDefault
repo_idNo
limitNo

TDQS

C2.4/5.0
Behavior2/5

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

No annotations provided; description only says 'list,' implying read-only. No disclosure of side effects, performance, or access requirements, leaving significant behavioral gaps.

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?

Single sentence is concise but lacks structural organization. It is front-loaded and to the point, but overly minimal for a tool with parameters.

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

Completeness1/5

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

With 2 parameters and no output schema, description fails to clarify what 'recent' means, how parameters work, or what the response contains. Very incomplete for effective use.

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

Parameters1/5

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

Schema coverage is 0%; description does not explain parameters repo_id or limit. Agent cannot infer their meaning or usage from the description alone.

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?

Description clearly states it lists recent durable project memories from a local log. Verb 'list' and resource are specific, and it distinguishes from search/remember tools. However, 'recent' is vague without time criteria.

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 vs siblings like brain_search or brain_remember. Lacks context on prerequisites or alternative scenarios.

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

brain_reindexC

Replay the local durable memory log into LightRAG.

ParametersJSON Schema
NameRequiredDescriptionDefault
repo_idNo
limitNo

TDQS

C2.5/5.0
Behavior2/5

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

No annotations are provided, and the description does not disclose side effects, prerequisites, or safety considerations (e.g., whether replaying is idempotent, what gets overwritten). The description carries the full burden and falls short.

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

Conciseness2/5

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

The single sentence is terse but omits critical details. It is underspecified rather than efficiently concise, especially given missing parameter explanations.

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

Completeness1/5

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

No output schema, no annotations, and incomplete parameter documentation. The description fails to provide enough context for correct tool invocation, e.g., return values, error behavior, or mechanism.

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

Parameters1/5

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

The input schema has 2 parameters with no descriptions, and the description adds zero information about 'repo_id' or 'limit'. With 0% schema description coverage, the description must compensate but does not.

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 a specific action ('Replay the local durable memory log into LightRAG'), with a verb and resource. It distinguishes from sibling tools like 'brain_recent' (list recent) and 'rag_index_repo' (index repository).

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 explicit guidance on when to use this tool versus alternatives like 'brain_recent' or 'rag_index_repo'. The context is implied but not clarified, leaving the agent with insufficient decision support.

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

brain_rememberB

Persist a durable project memory into the local memory log and LightRAG. Use this after fixes, failed attempts, setup discoveries, architecture decisions, and session handoff notes.

ParametersJSON Schema
NameRequiredDescriptionDefault
kindNolesson
titleYes
summaryYes
detailsNo
outcomeNo
repo_idNorepo1
filesNo
tagsNo

TDQS

B3.3/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 disclose behavioral traits. It only states that the tool persists memories into two stores (local memory log and LightRAG) but does not describe side effects, authorization needs, or whether it appends or overwrites. This is insufficient for a write operation.

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 two sentences, front-loads the action and resource, and contains no extraneous information. Every sentence is purposeful.

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?

Despite a clear purpose and usage context, the description fails to provide enough information for the agent to correctly invoke the tool, especially given the 0% parameter coverage, missing output schema, and no annotations. The agent lacks guidance on how to fill parameters and what to expect.

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

Parameters1/5

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

With 0% schema description coverage and 8 parameters, the description adds no meaning to any parameter. The agent must infer all parameter semantics from names and enums alone, which is inadequate.

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 a specific verb ('persist') and clearly identifies the resource ('durable project memory', 'local memory log and LightRAG'). It also distinguishes itself from sibling tools like brain_begin and brain_finish by focusing on memory storage after specific events.

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 lists when to use the tool ('after fixes, failed attempts, setup discoveries, architecture decisions, and session handoff notes'), providing good context. However, it does not specify when not to use it or mention alternatives.

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

profile_bootstrapC

Build or refresh the structured senior-developer project profile from repository layout and project instruction files.

ParametersJSON Schema
NameRequiredDescriptionDefault
rootNo/app
repo_idNorepo1

TDQS

C2.9/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 disclose behavioral traits. It mentions 'Build or refresh' implying mutation, but does not specify whether it overwrites, requires permissions, or has side effects. The description lacks detail on the degree of destructiveness or safety.

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 it sacrifices completeness. It front-loads the purpose but omits necessary details, making it too brief for adequate understanding.

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 output schema, no annotations, and two undocumented parameters, the description is insufficient for an agent to understand how to invoke the tool correctly. Important details about input, output, and behavior are missing.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not mention the two parameters ('root' and 'repo_id') at all. The agent receives no guidance on what these parameters control or how to use them.

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's action ('Build or refresh') and the specific resource ('structured senior-developer project profile'). It also distinguishes from sibling tools like 'profile_get' and 'profile_search' by focusing on creation/refresh rather than retrieval.

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 for building or refreshing a profile but provides no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or context for use.

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

profile_getC

Return the structured senior-developer project profile.

ParametersJSON Schema
NameRequiredDescriptionDefault
sectionsNo
markdownNo

TDQS

C2.4/5.0
Behavior1/5

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

With no annotations, the description must fully disclose behavioral traits. It only states 'Return the structured senior-developer project profile' but does not specify whether it is read-only, what happens if parameters are omitted, side effects, or return format. Critical behavioral context is missing.

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, front-loaded sentence with no wasted words. However, it is under-specified, missing important details that could be added without harming conciseness. It earns its place but could be more informative.

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 2 parameters, no output schema, and no annotations, the description is insufficient. It does not explain return values, how parameters affect output, or any prerequisites. Compared to sibling tools, more context is needed for correct use.

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

Parameters1/5

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

Schema description coverage is 0%, so the description must explain parameter meanings. It does not mention 'sections' (array of enum values) or 'markdown' (boolean) at all. The description adds no value beyond the schema, leaving the agent without guidance on parameter usage.

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 a specific verb ('Return') and resource ('structured senior-developer project profile'), which is clear. However, it does not distinguish this tool from siblings like 'profile_search' or 'profile_upsert', which also deal with profiles. The purpose is understandable but lacks sibling differentiation.

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 'profile_search' or 'profile_bootstrap'. There is no mention of prerequisites, context, or exclusion criteria. The description offers no usage recommendations.

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

profile_upsertC

Create or update one senior-developer knowledge item in the project profile and index it into LightRAG.

ParametersJSON Schema
NameRequiredDescriptionDefault
sectionYes
titleYes
summaryYes
detailsNo
repo_idNorepo1
filesNo
tagsNo

TDQS

C2.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions mutation and indexing but omits details like overwrite behavior, permissions, rate limits, or side effects. For a mutating tool, this is insufficient.

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 lacks structure. It is front-loaded with the verb, but the brevity sacrifices important details.

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

Completeness1/5

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

Given the tool has 7 parameters, 3 required, no output schema, and no annotations, the one-sentence description is severely incomplete. It does not explain parameter roles, return values, or behavioral nuances.

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

Parameters1/5

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

Schema description coverage is 0%, yet the description provides no explanation of any parameters. The seven parameters (including required ones) are left entirely undocumented, forcing the agent to rely solely on the schema.

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 verb (create/update), resource (knowledge item in project profile), and additional action (index into LightRAG). It distinguishes from sibling tools like profile_get and profile_search which are read-only, but does not explicitly differentiate from brain_remember, which might have similar purpose.

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 such as profile_bootstrap, profile_get, or brain_remember. The description lacks context for decision-making.

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

rag_askA

Query the local LightRAG knowledge base for repository context. Use this before answering questions about code architecture, historical decisions, indexed docs, or cross-file behavior.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesQuestion to ask LightRAG.
modeNohybrid
include_referencesNo
top_kNo
chunk_top_kNo
include_chunk_contentNo

TDQS

A3.5/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It only states that the tool queries and is for context, but does not disclose whether it is read-only, destructive, or any other behavioral traits such as rate limits or error handling. For a query tool, it should at least imply safety.

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 redundant information. The first sentence defines the action and resource, the second provides usage guidance. Every word adds value.

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 complexity (6 parameters, no output schema), the description is too brief. It does not explain return values, behavior of different modes, or how to handle pagination or empty results. For a query tool, more completeness is needed.

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 description coverage is only 17% (only 'query' is described). The description adds context on the tool's purpose but provides no details on parameters like 'mode' (enum values), 'top_k', or 'include_references'. This is insufficient to compensate for the lack of schema descriptions.

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 'Query' and the resource 'local LightRAG knowledge base for repository context'. It also specifies when to use it (before answering questions about code architecture, etc.), helping distinguish from sibling tools like rag_query_data or rag_index_repo.

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 advises using this tool before answering specific types of questions (code architecture, historical decisions, etc.). However, it does not mention when not to use it or provide alternatives among the many siblings, leaving some ambiguity.

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

rag_cancel_pipelineA

Cancel the active LightRAG document processing pipeline, if any.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses the action (cancel) and condition (if active), but does not detail side effects, reversibility, or result. This is adequate but not thorough.

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 concise sentence that directly states the tool's purpose with no extraneous words. It is 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 the tool has no parameters, no output schema, and a simple action, the description covers the essential: what it does and when it applies. It is adequately complete for the tool's simplicity.

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?

There are no parameters; the schema coverage is 100%. The description adds no param information, which is expected. The baseline of 4 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?

The description clearly specifies the verb 'Cancel' and the resource 'active LightRAG document processing pipeline'. It distinguishes itself from sibling tools by being the only cancellation operation.

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 states the condition 'if any', indicating to use only when a pipeline is active. Although it lacks explicit exclusions or alternatives, the context is clear and sufficient for the simple cancel operation.

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

rag_clearC

Clear LightRAG documents and/or cache. Destructive.

ParametersJSON Schema
NameRequiredDescriptionDefault
documentsNo
cacheNo

TDQS

C2.6/5.0
Behavior2/5

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

With no annotations, the description carries full burden. It only labels the operation as 'Destructive' without detailing what gets destroyed (documents, cache, or both), irreversibility, or permission requirements. This is insufficient for a potentially data-loss operation.

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 very short (two sentences), which is concise but sacrifices necessary details for a destructive tool. It is front-loaded with purpose but lacks structured warnings or examples.

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 output schema and 0% parameter coverage, the description is incomplete. It does not explain return values, side effects, or when to use each parameter. A destructive tool warrants more comprehensive context.

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 0%, and the description does not explain the parameters beyond their names. 'documents' and 'cache' are somewhat intuitive, but no additional semantics or usage examples are provided, failing to compensate for the schema gaps.

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 tool clears LightRAG documents and/or cache, with a specific verb and resource. It distinguishes from siblings by focusing on clearing, but lacks specificity about what 'clear' entails (e.g., deletion, truncation).

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 vs alternatives like rag_ask or rag_status. The word 'Destructive' hints at caution but doesn't specify prerequisites or contexts where clearing is appropriate.

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

rag_get_contextA

Retrieve LightRAG context for a query without generating a final answer.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesQuestion to ask LightRAG.
modeNohybrid
include_referencesNo
top_kNo
chunk_top_kNo
include_chunk_contentNo

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses the core behavior (no final answer generation) but omits details like auth needs, rate limits, or whether the operation is read-only. Adequate but not thorough.

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 concise sentence that front-loads the key action and distinction, with no wasted words.

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 has 6 parameters, no output schema, and no annotations, the description is too minimal. It does not explain the return format, result structure, or any constraints, making it incomplete 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.

Parameters2/5

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

Schema description coverage is only 17% (only 'query' has a description), and the tool description adds no information about the other 5 parameters (mode, top_k, etc.). This leaves the agent without sufficient guidance for parameter 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 specific verb (Retrieve) and resource (LightRAG context), and explicitly distinguishes from generating a final answer, which is a key difference from sibling tools like rag_ask.

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 the tool is for getting context without an answer, but lacks explicit guidance on when to use vs. alternatives (e.g., rag_ask), and no when-not-to-use or prerequisites are mentioned.

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

rag_index_repoB

Index a repository into LightRAG. Multi-repo support is provided by prefixing every source with repo_id:relative/path.

ParametersJSON Schema
NameRequiredDescriptionDefault
rootNoRepository root to index./app
repo_idNoStable repository identifier used as source prefix.repo1
include_extensionsNo
exclude_dirsNo
exclude_file_namesNo
exclude_suffixesNo
max_file_bytesNo
limitNo
dry_runNo
redact_secretsNo

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It only hints at the prefixing mechanism but omits critical details like the index's persistence, idempotency, side effects on previous indexes, or performance impact. The mutability is implicit but not explicitly stated.

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 tightly written sentences that front-load the core purpose and immediately follow with a key design detail (multi-repo support). Every word contributes value, with no redundancy or fluff.

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—10 parameters, no output schema, and many sibling tools—the description is severely under-informative. It lacks any mention of prerequisites (e.g., LightRAG status), error scenarios, return behavior, or how this index coexists with other 'rag_' and 'brain_' tools. The description answers only the most basic 'what' question.

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 description coverage is low (20%), and while the schema itself contains descriptions for each parameter, the tool's description adds minimal meaning beyond the schema. The only added insight is linking 'repo_id' to the prefixing strategy, which the schema already mentions. For the remaining 8 parameters, the description provides no additional context.

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 'index' and the resource 'a repository into LightRAG,' making the tool's purpose specific and distinct from sibling tools like 'rag_ask' or 'brain_remember.' The mention of multi-repo support further clarifies its scope.

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?

The description provides no explicit guidance on when to use this tool versus alternatives (e.g., 'brain_reindex' or 'rag_clear'), nor does it mention prerequisites or exclusion criteria. The usage context is entirely implied.

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

rag_list_documentsC

List indexed documents, optionally filtered by repo_id prefix.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNo
page_sizeNo
statusNo
repo_idNo

TDQS

C2.9/5.0
Behavior2/5

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

No annotations provided; description does not disclose read-only nature, pagination defaults, or side effects. It only mentions filtering by repo_id prefix.

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?

Single sentence is concise but omits important details like pagination behavior and return format. Could include more information without being verbose.

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?

No output schema; description does not explain what the tool returns. Lacks details on pagination, status filtering, and default behavior, making it incomplete for effective use.

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 0%; description only explains repo_id (prefix filter), but not page, page_size, or status. Fails to compensate for missing schema descriptions.

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 it lists indexed documents with optional filtering by repo_id prefix. Verb 'list' and resource 'indexed documents' are specific, and it distinguishes from siblings like rag_query_data and rag_search.

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 rag_query_data or rag_search. No context on prerequisites or exclusions.

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

rag_query_dataC

Return structured LightRAG query data: entities, relations, chunks, and metadata.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesQuestion to ask LightRAG.
modeNohybrid
include_referencesNo
top_kNo
chunk_top_kNo
include_chunk_contentNo

TDQS

C2.9/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 carry the burden. It does not disclose any behavioral traits such as read-only nature, required permissions, performance implications, or behavior on empty results. For a tool with 6 parameters, this is insufficient.

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 sentence that directly states the purpose. It is concise but could be improved by adding key behavioral details without becoming verbose.

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 has 6 parameters, no output schema, and no annotations, the description is insufficient. It does not explain return format, modes, or how parameters affect results. The agent would need external knowledge to use this tool effectively.

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 description coverage is only 17% (only query has a description in schema). The tool description adds no parameter details beyond the schema. It fails to compensate for the low coverage, leaving agents without understanding of mode, top_k, include_references, etc.

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 returns structured LightRAG query data including entities, relations, chunks, and metadata. It uses a specific verb 'Return' and resource 'LightRAG query data', and distinguishes from sibling tools like rag_ask (text answer) and rag_get_context (context only).

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. There is no mention of use cases, prerequisites, or comparison with siblings like rag_ask or rag_get_context. The agent lacks information to choose appropriately.

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

rag_reprocess_failedB

Ask LightRAG to reprocess failed documents.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3/5.0
Behavior2/5

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

No annotations provided; description merely says 'reprocess' without disclosing side effects, authorization needs, or whether it is safe/read-only. The agent gets no behavioral insight beyond the verb.

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 is efficient, but could be slightly more descriptive without being lengthy. Front-loaded with action verb.

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?

Lacks context for a zero-parameter tool: what happens when invoked? Is there a confirmation? What does 'reprocess' mean? No output schema or annotations to compensate.

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?

With zero parameters and 100% schema coverage, the description adds no parameter details, but none are needed. The baseline of 4 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?

Description clearly states verb ('reprocess') and resource ('failed documents'), distinguishing it from siblings like rag_ask or rag_clear that have different purposes. However, it doesn't specify what 'reprocess' entails.

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. The phrase 'Ask LightRAG' is vague and doesn't set context or exclusions.

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

rag_statusA

Check LightRAG health, active models, and document pipeline state.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.3/5.0
Behavior4/5

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

No annotations are provided, so the description must disclose behavior. It clearly states the tool is for checking health, active models, and pipeline state, implying a read-only operation. No side effects are mentioned, but the description is sufficient for a simple status check.

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 concise sentence that immediately conveys the purpose. No unnecessary words.

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?

Given the tool has no parameters, no output schema, and is a straightforward read-only health check, the description provides all necessary context for an agent to understand and invoke it correctly.

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?

The tool has zero parameters, so the description cannot add parameter meaning. With 100% schema coverage, the baseline is 4, and no further information is needed.

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 checks LightRAG health, active models, and document pipeline state. It uses a specific verb (check) and resource (LightRAG), distinguishing it from sibling tools like rag_track_status which may focus on tracking over time.

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 for checking current status but does not explicitly state when to use this tool versus alternatives like rag_track_status or when not to use it. Guidance is minimal.

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

rag_track_statusC

Get processing status for a LightRAG track_id.

ParametersJSON Schema
NameRequiredDescriptionDefault
track_idYes

TDQS

C2.7/5.0
Behavior2/5

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

With no annotations, the description carries full burden but only says 'get processing status'. It does not disclose behaviors like whether the operation is read-only, what happens with invalid track_ids, or any side effects.

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 that is concise and front-loaded. Every word earned its place, but could be expanded with more useful detail without losing conciseness.

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?

For a tool with no output schema and many siblings, the description is too thin. It doesn't explain what 'processing status' means, possible return values, or error scenarios, making it incomplete for an AI agent.

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 0%, so description must compensate. It mentions 'LightRAG track_id' which adds minimal context, but no details on format, source, or constraints beyond the schema.

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 it gets processing status for a track_id, with a specific verb and resource. However, it does not differentiate from sibling tools like 'rag_status' or 'brain_gate_status', which might serve similar purposes.

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, no prerequisites or context provided. The description simply states the function without usage context.

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

rag_webuiA

Return local LightRAG Web UI and API documentation URLs.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

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 burden. It clearly states the tool returns URLs, implying a read-only operation with no side effects. While it does not mention potential errors (e.g., server not running), the simplicity of the tool makes this sufficient.

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 with no unnecessary words. It front-loads the action and resource, achieving maximum conciseness for a tool with no parameters.

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?

Given the tool has no parameters, no output schema, and is a simple information retrieval, the description is fully complete. It explains exactly what the tool returns and leaves no ambiguity.

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?

The tool has no parameters, and the description does not need to add meaning beyond the schema. The schema coverage is 100%, so a baseline of 4 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?

The description uses the specific verb 'Return' and identifies the resource as 'URLs' for the local LightRAG Web UI and API documentation. It clearly distinguishes itself from sibling tools like rag_ask and rag_status, which focus on data operations.

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 the tool is used to retrieve documentation URLs, but provides no explicit guidance on when to use it versus alternatives or any exclusions. The context of sibling tools suggests its unique role, but the description itself lacks direct usage instructions.

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

senior_briefC

Return a senior-developer brief for a topic: architecture profile, conventions, hazards, workflows, and related durable memories.

ParametersJSON Schema
NameRequiredDescriptionDefault
topicNocurrent task
repo_idNo
memory_limitNo
top_kNo
chunk_top_kNo

TDQS

C2.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. The description states what the tool returns but does not disclose behavioral traits such as whether it modifies state (likely read-only), authentication requirements, rate limits, or whether it aggregates from multiple stores. This lack of behavioral context is a significant gap.

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 concise sentence that front-loads the purpose. It is efficient but lacks structure; no separate sections for when to use or parameter details. Given the missing information, it could benefit from more structure, but it stays on point.

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

Completeness1/5

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

The tool has 5 parameters, no output schema, and no annotations. The description only covers the output content but omits crucial context: parameter meanings, return format, side effects, and how it differs from sibling tools. For such a complex tool, the description is severely incomplete.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not explain any of the five parameters (topic, repo_id, memory_limit, top_k, chunk_top_k). Parameter names hint at their purpose but are not officially documented. The description adds no semantic value beyond the schema's type and default values.

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 tool returns a 'senior-developer brief' for a topic, listing specific components (architecture profile, conventions, hazards, workflows, related durable memories). It effectively distinguishes the tool from siblings like 'brain_search' (which searches memories) or 'profile_get' (which gets a profile). However, it could be more precise about the verb.

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?

The description does not provide any guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or relationships to other tools like 'rag_query_data' or 'profile_get'. The agent must infer usage from the purpose.

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. Dates show when Glama detected each change.

  1. 23 tool updatesv0.1.0
    • First observedbrain_begin
    • First observedbrain_finish
    • First observedbrain_gate_status
    • First observedbrain_recent
    • First observedbrain_reindex
    • First observedbrain_remember
    • First observedbrain_search
    • First observedprofile_bootstrap
    • First observedprofile_get
    • First observedprofile_search
    • First observedprofile_upsert
    • First observedrag_ask
    • First observedrag_cancel_pipeline
    • First observedrag_clear
    • First observedrag_get_context
    • First observedrag_index_repo
    • First observedrag_list_documents
    • First observedrag_query_data
    • First observedrag_reprocess_failed
    • First observedrag_status
    • First observedrag_track_status
    • First observedrag_webui
    • First observedsenior_brief
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.1/5.0
Disambiguation4/5

Most tools have distinct purposes, especially within groups. However, brain_search, rag_ask, and profile_search all involve searching different stores, which could cause confusion if descriptions are not carefully read.

Naming Consistency4/5

Tools follow a consistent verb_noun pattern with lowercase underscores, except 'senior_brief' which lacks a verb prefix. The pattern is clear within each prefix group (brain_, profile_, rag_).

Tool Count4/5

23 tools is slightly on the higher side but still reasonable for a comprehensive memory and knowledge server. Each tool serves a specific function, and the count is not excessive.

Completeness3/5

The tool set covers core workflow, memory, profile, and RAG operations, but lacks delete/update tools for memories and profiles, and document-level deletion. Minor gaps exist but most use cases are addressed.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • MCP Memory Server

    beach55607-max
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides long-term memory for AI coding agents, enabling them to remember, search, and organize information across sessions and platforms like Claude Code, ChatGPT, and Cursor.
    18
    9
    MIT

  • lens

    tools-for-agents
    A
    license
    Not graded
    quality
    B
    maintenance
    Provides token-efficient code retrieval for coding agents by indexing repositories and enabling ranked snippet search, symbol outlines, and surgical line reads.
    MIT

  • CodeMind

    twly7ho2
    F
    license
    Not graded
    quality
    C
    maintenance
    Provides persistent codebase memory and semantic context for AI agents via AST-aware chunking and symbol graph indexing.
    1
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Filmystar/lightrag-code-brain-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server