Check whether LightRAG is reachable AND whether this server's credentials actually work. GET /health alone is not enough: it is a public liveness probe that returns 200 even with a missing or wrong API key, so this tool also calls get_document_status_counts (which does enforce auth) and lets any failure from that call raise -- this tool never reports healthy while authentication is broken, which was the old lightrag-mcp wrapper's exact trap.

Answer a question using the knowledge base (RAG). Use this for any question about the content stored in LightRAG -- it retrieves relevant context and has an LLM compose the answer. Returns response (the answer text) and, by default, references (the source documents it drew on).

Retrieve the raw entities, relationships and text chunks relevant to a question, WITHOUT having LightRAG's LLM compose an answer. Use this instead of query when the caller (e.g. Hermes) wants to compose its own answer from the retrieved evidence. Always includes references.

List documents in the knowledge base, with pagination. This is the tool to use for "how many documents are there" or "list the documents" -- do not conclude the knowledge base is empty from a tool failure; that means LightRAG could not be reached, not that there are zero documents (this is the exact bug this server exists to fix). Returns a trimmed per-document summary (id, file_path, status, chunks_count, updated_at, error_msg if any) plus total_count and has_next.

Get the count of documents in each processing status (pending, processing, processed, failed, ...). The fast, low-context way to answer "how many documents does LightRAG have" -- prefer this over list_documents when only the counts are needed.

Check what LightRAG's indexing pipeline is doing right now: busy or idle, current job name and progress, and the most recent status messages. Use this for "what is LightRAG processing" -- by default returns a short summary (the last 10 history lines), not the full internal state; pass verbose=true only if the summary is not enough.

Check the processing status of the document(s) associated with a track_id -- use this after insert_text/insert_texts/upload_file to see whether indexing finished, and whether it succeeded.

List the file extensions LightRAG accepts for upload, and which parser engine handles each. Check this before upload_file if the file's extension is not obviously supported.

Check the progress of a background folder scan started by scan_documents.

List documents whose source file name collides with another document's (a "source conflict") -- these were never auto-resolved because picking a winner automatically could retire the wrong document. Use repair_source_conflict to resolve one.

Insert a single piece of raw text into the knowledge base for indexing. Returns a track_id -- poll with get_track_status to see when indexing finishes.

Insert multiple pieces of raw text into the knowledge base in one call. Returns a single track_id covering the whole batch -- poll with get_track_status.

Upload and index a single file already present on disk. Checks the file exists and its extension is supported before uploading -- call get_supported_file_types first if unsure. Returns a track_id; poll with get_track_status.

Upload every supported file directly inside a directory, one by one, reporting each file's own outcome -- unsupported extensions are skipped (not treated as errors), and one file failing does not stop the rest. Use this instead of calling upload_file in a loop.

Trigger a background scan of LightRAG's input directory for new files not yet indexed. Returns a track_id; poll with get_scan_status. Refuses with status='scanning_skipped_pipeline_busy' if a scan or the indexing pipeline is already running.

Retry documents currently in a failed, pending, or interrupted state, without rescanning the input directory for new files.

DESTRUCTIVE: permanently deletes documents and all their associated data (status, text chunks, vector embeddings, related graph data). This cannot be undone. Runs in the background; use get_track_status or list_documents afterward to confirm.

DESTRUCTIVE: permanently deletes EVERY document in the knowledge base. This cannot be undone -- confirm with the user before calling this.

DESTRUCTIVE: force-clears a 'recovery_required' fence that blocks every mutation after a worker died mid-operation. This reopens a possibly-inconsistent workspace and cannot be undone -- use only to recover a stuck pipeline, and only after checking get_pipeline_status first. No-ops (status='no_recovery_required') if nothing is fenced.

Request cancellation of the currently-running indexing pipeline job. Documents already in progress will be marked FAILED. Use get_pipeline_status first to see what would be cancelled; returns status='not_busy' if nothing is running.

Resolve a source-name conflict (from list_source_conflicts) by naming one document as the primary. Always dry_run first to see what would change; committing (dry_run=false) marks the other candidates as duplicates -- their content is not deleted, but this still cannot be trivially undone, so double-check the dry-run result first.

List every entity label (name) currently in the knowledge graph. Can be long on a large knowledge base -- prefer get_popular_labels or search_labels when looking for something specific.

List entity labels sorted by how connected they are (node degree), most-connected first -- a quick way to see what the knowledge graph is mostly about.

Find entity labels whose name fuzzy-matches a search string. Use this to locate entities related to a topic before asking about them with query, or before get_knowledge_graph.

Retrieve a connected subgraph (nodes and edges) around one entity label. Nodes closer to the label, and more connected nodes, are kept first when the graph is larger than max_nodes.

Check whether an entity with an exact name already exists in the knowledge graph. Call this before create_entity or edit_entity (rename) to avoid an unintended collision.

Create a new entity in the knowledge graph. Call check_entity_exists first to avoid an unintended duplicate.

Update an entity's properties, optionally renaming it (and merging it into an existing entity of the same new name, if allowed).

Create a relationship between two entities that both already exist in the knowledge graph.

Update the properties of an existing relationship between two entities.

Merge one or more duplicate or misspelled entities into a single target entity. The merged-from entities are removed once this succeeds and this cannot be undone -- double check the names first.

DESTRUCTIVE: permanently deletes an entity and all its relationships from the knowledge graph. This cannot be undone.

DESTRUCTIVE: permanently deletes the relationship between two entities from the knowledge graph. This cannot be undone. The entities themselves are not deleted.