Your codebase needs a knowledge graph (not just vector search)

Vector search is everywhere. RAG this, embedding that. But when your coding agent needs to understand how your authentication system connects to your user model, or which services depend on a particular API endpoint, vector similarity falls flat.

Your codebase isn't just text to search through — it's a network of relationships. Functions call other functions. Classes inherit from base classes. Services depend on other services. Routes map to controllers. This is graph data, not document data.

I've been running a knowledge graph MCP server for my main codebase for three months. Instead of asking "find me files about authentication," I can ask "show me everything that depends on the User model" or "trace the path from this API endpoint to the database."

Here's how it works. The MCP server maintains a graph database that tracks:

• Structural relationships: imports, inheritance, function calls
• Data flow: which functions read/write which data structures
• API boundaries: which routes connect to which services
• Test coverage: which tests cover which code paths

When my coding agent needs to modify the user registration flow, it doesn't just search for "user registration." It queries the graph:

MATCH (endpoint:Route {path: '/register'})-[:CALLS]->(handler:Function)
MATCH (handler)-[:USES]->(model:Class {name: 'User'})
MATCH (model)-[:HAS_METHOD]->(method:Function)
RETURN endpoint, handler, model, method

The result? My agent understands that changing the User model's validation logic will affect the registration endpoint, the profile update endpoint, and the admin user management system. It knows to check the corresponding tests. It knows which API docs need updating.

This isn't theoretical. Last week, my agent traced a performance issue from a slow API endpoint through three service layers to find the N+1 query buried in a utility function. Vector search would have found the endpoint file. The knowledge graph found the root cause.

The setup is straightforward. Run a static analysis tool (I use tree-sitter) to extract the structural relationships. Feed them into a graph database (Neo4j works, but SQLite with recursive CTEs is fine for most codebases). Expose it through an MCP server.

The key insight: your codebase's structure is the context your agent needs. Don't embed it away into vectors. Make it queryable as a first-class data structure.

Your coding agent stops guessing about dependencies and starts reasoning about architecture. The difference is dramatic.