# How the ingest_traces Tool Validates HTTP_CALLS Edges with Runtime Traces

> Learn how the ingest_traces tool validates HTTP_CALLS edges and runtime traces. Understand the current limitations and future capabilities of this essential codebase analysis feature.

- Repository: [Martin Vogel/codebase-memory-mcp](https://github.com/DeusData/codebase-memory-mcp)
- Tags: how-to-guide
- Published: 2026-07-28

---

**The ingest_traces MCP tool currently accepts runtime trace data but does not validate HTTP_CALLS edges; it only parses the JSON payload, counts the traces, and returns a placeholder response indicating that runtime edge creation is not yet implemented.**

The `ingest_traces` tool in the **DeusData/codebase-memory-mcp** repository is designed to bridge static analysis with runtime observability by accepting trace data that could confirm or create `HTTP_CALLS` edges in the knowledge graph. However, as implemented in the current C codebase, the tool acts as a stub that acknowledges receipt of trace arrays without performing actual graph validation or mutation.

## Current Implementation in src/mcp/mcp.c

The core logic resides in the `handle_ingest_traces` function within [`src/mcp/mcp.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/mcp/mcp.c). This function processes incoming JSON-RPC requests but explicitly defers edge validation to a future release.

### Parsing the JSON Payload with yyjson

The tool uses the **yyjson** library to extract the `traces` array from the incoming arguments:

```c
yyjson_doc *adoc = yyjson_read(args, strlen(args), 0);
yyjson_val *aroot = yyjson_doc_get_root(adoc);
yyjson_val *traces = yyjson_obj_get(aroot, "traces");

```

(See [`src/mcp/mcp.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/mcp/mcp.c), lines 10315‑10322.)

### Counting Received Traces

Rather than inspecting individual trace contents, the implementation simply calculates the array size:

```c
int trace_count = (int)yyjson_arr_size(traces);

```

This count is used solely for the response payload and does not drive any graph operations.

### Returning the Placeholder Response

The function constructs a JSON reply that admits the limitation explicitly:

```c
yyjson_mut_obj_add_str(doc, root, "status", "accepted");
yyjson_mut_obj_add_int(doc, root, "traces_received", trace_count);
yyjson_mut_obj_add_str(doc, root,
     "note", "Runtime edge creation from traces not yet implemented");

```

This response confirms the server received the data while making clear that `HTTP_CALLS` edge validation remains unimplemented (see [`src/mcp/mcp.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/mcp/mcp.c), lines 10331‑10335).

## The Planned HTTP_CALLS Validation Workflow

While the current code stops at acknowledgment, the repository structure suggests a future implementation that would:

- Extract HTTP request/response details (URL, method, status code) from each trace object
- Match runtime data against existing `HTTP_CALLS` edges linking caller functions to route nodes
- Identify mismatches or missing edges, potentially inserting new `HTTP_CALLS` edges where static analysis failed to detect runtime calls

The [`src/traces/traces.h`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/traces/traces.h) header file declares trace-related structures intended to support this future expansion.

## Client-Side Usage Example

To submit traces to the MCP server, clients send a JSON-RPC request structured as follows:

```json
{
  "name": "ingest_traces",
  "params": {
    "project": "my-project",
    "traces": [
      { "type": "http", "method": "GET", "url": "/api/users", "status": 200 },
      { "type": "http", "method": "POST", "url": "/api/orders", "status": 201 }
    ]
  }
}

```

The server-side handler processes this through the `handle_ingest_traces` function shown below:

```c
static char *handle_ingest_traces(cbm_mcp_server_t *srv, const char *args) {
    (void)srv;
    yyjson_doc *adoc = yyjson_read(args, strlen(args), 0);
    int trace_count = 0;

    if (adoc) {
        yyjson_val *aroot = yyjson_doc_get_root(adoc);
        yyjson_val *traces = yyjson_obj_get(aroot, "traces");
        if (traces && yyjson_is_arr(traces)) {
            trace_count = (int)yyjson_arr_size(traces);
        }
        yyjson_doc_free(adoc);
    }

    yyjson_mut_doc *doc = yyjson_mut_doc_new(NULL);
    yyjson_mut_val *root = yyjson_mut_obj(doc);
    yyjson_mut_doc_set_root(doc, root);
    yyjson_mut_obj_add_str(doc, root, "status", "accepted");
    yyjson_mut_obj_add_int(doc, root, "traces_received", trace_count);
    yyjson_mut_obj_add_str(doc, root,
        "note", "Runtime edge creation from traces not yet implemented");

    char *json = yy_doc_to_str(doc);
    yyjson_mut_doc_free(doc);
    char *result = cbm_mcp_text_result(json, false);
    free(json);
    return result;
}

```

The resulting JSON response looks like:

```json
{
  "status": "accepted",
  "traces_received": 2,
  "note": "Runtime edge creation from traces not yet implemented"
}

```

## Unit Test Coverage

The current behavior is verified in [`tests/test_mcp.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/tests/test_mcp.c) and [`tests/test_incremental.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/tests/test_incremental.c). These test suites assert that the JSON response contains `"status":"accepted"` and a correct `traces_received` count, but they do not assert any graph mutations or `HTTP_CALLS` edge validations, reflecting the tool's current stub status.

## Summary

- The `ingest_traces` tool in [`src/mcp/mcp.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/mcp/mcp.c) currently acts as a stub that accepts trace arrays but performs no validation of `HTTP_CALLS` edges.
- The `handle_ingest_traces` function uses **yyjson** to parse incoming JSON and count trace entries.
- The tool explicitly returns `"Runtime edge creation from traces not yet implemented"` to indicate that validation is pending.
- Future releases will extend the implementation to extract HTTP details and validate or create edges in the knowledge graph according to the runtime traces.

## Frequently Asked Questions

### Does ingest_traces currently create HTTP_CALLS edges in the knowledge graph?

No. As of the current implementation in DeusData/codebase-memory-mcp, the tool only parses the JSON payload and counts the traces. It returns a placeholder response indicating that runtime edge creation is not yet implemented, and it performs no graph mutations or edge validations.

### What is the intended future behavior for HTTP_CALLS validation?

The planned implementation would extract HTTP request/response information (URL, method, status code) from each trace, match this data against existing `HTTP_CALLS` edges linking caller functions to route nodes, and create new edges where runtime traces reveal calls that static analysis missed.

### How does the tool parse incoming trace data?

The `handle_ingest_traces` function in [`src/mcp/mcp.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/mcp/mcp.c) uses the yyjson library to read the JSON arguments, extract the root object via `yyjson_doc_get_root`, and retrieve the `traces` array via `yyjson_obj_get`. It then counts the array size with `yyjson_arr_size` without inspecting individual trace objects.

### Where can I find the implementation of ingest_traces?

The server-side implementation resides in [`src/mcp/mcp.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/mcp/mcp.c) within the `handle_ingest_traces` function. Unit tests covering the current acknowledgment behavior are located in [`tests/test_mcp.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/tests/test_mcp.c) and [`tests/test_incremental.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/tests/test_incremental.c).