# Retrieval
> How a query travels from a client or agent to an answer from the graph.
[Source](https://open.nxtsoft.io/docs/cgraph/retrieval)

Retrieval is the read path: a client or agent asks a question, the daemon answers
it from the warm graph. Every front door funnels through one operation handler.

## Query execution

_One operation handler behind every front door_

```text
cgraph-client ─┐
               ├─ JSON op ─> graphd operation handler ─> warm graph ─> JSON result
cgraph-mcp   ─┘
```

The thin client sends an operation and a JSON payload to the daemon:

**a query**

```bash
cgraph-client --root /path/to/project query '{"q":"Parser"}'
```

MCP tool calls route through the **same daemon operation handler** as the thin
client, so an agent and a shell get identical semantics.

## The operations

- **`query`** — find nodes matching a query.
- **`explain`** — explain a node and its role.
- **`impact`** — the transitive blast radius of a change.
- **`path`** — the shortest path between two symbols.
- **`context`** — a packed neighborhood for an agent (see [Context Packing](/docs/cgraph/context-packing)).
- **`update`** / **`status`** / **`shutdown`** — maintenance and introspection.

## Responses

Responses are JSON. A `status` response, for example, reports daemon process
metadata, graph node and edge counts, cache hit rate, and semantic enrichment
state — enough to tell whether the graph is ready and how warm the cache is.

The client–daemon wire transport (socket type, framing) is not detailed in the
public README; the MCP transport is documented on the
[MCP Integration](/docs/cgraph/mcp) page. This page describes the
operation semantics, which are stated; the transport specifics are pending.