How the ingest_traces Tool Validates HTTP_CALLS Edges with Runtime Traces

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. 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:

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, lines 10315‑10322.)

Counting Received Traces

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

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:

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, 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 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:

{
  "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:

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:

{
  "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 and 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 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 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 within the handle_ingest_traces function. Unit tests covering the current acknowledgment behavior are located in tests/test_mcp.c and tests/test_incremental.c.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}