get_graph_labels always returns empty arrays despite populated knowledge graph

[magnus919]

Summary

The get_graph_labels MCP tool always returns {"entity_labels": [], "relation_labels": []} even when the LightRAG knowledge graph is fully populated with entities and relations.

Observed Behavior

Calling get_graph_labels returns:

{
  "entity_labels": [],
  "relation_labels": []
}

This happens even with a knowledge graph containing 1000+ nodes and 3600+ edges — confirmed by get_knowledge_graph returning the full graph correctly, and pipeline status logs showing successful entity/relation extraction (e.g. "Chunk 1 of 1 extracted 16 Ent + 12 Rel").

Root Cause

There is a field name mismatch between client.py and server.py.

In client.py, the /graph/label/list API response (a list) is wrapped as:

if isinstance(response_data, list):
    response_data = {"labels": response_data}
return LabelsResponse(**response_data)

This creates a LabelsResponse object with a single labels field.

In server.py, the handler then does:

result_dump = result.model_dump()
entity_labels = result_dump.get('entity_labels', [])
relation_labels = result_dump.get('relation_labels', [])

Since LabelsResponse has a labels field (not entity_labels or relation_labels), both .get() calls return the default empty list every time.

Proposed Fix

Option A — Update the server handler to read the correct key:

labels = result_dump.get('labels', [])
# return labels directly

Option B — Update the client to produce the field names the server expects:

response_data = {"entity_labels": response_data, "relation_labels": []}

Note: Option B silently assumes the LightRAG /graph/label/list endpoint only returns entity labels. If the endpoint (or a sibling endpoint) supports separate entity vs. relation label retrieval, the client should call them separately and populate both fields correctly.

Additional Notes

• get_knowledge_graph works correctly and returns full graph data
• • get_pipeline_status works correctly and shows entity/relation extraction completing successfully
• • • This appears to be the only tool affected by this specific mismatch