Beyond Text: The Semantic Layers Agents Need

In my previous post — From Grep to Graph — I argued that coding agents fail not because they lack intelligence, but because they lack structure. They still see software as text, not as a system of relationships, histories, and behaviors.

But once you start thinking in graphs, another realization follows naturally: a graph is only useful if the agent can query it.

That’s where the new generation of MCP servers comes in. GitNexus, Codebase‑Memory‑MCP, Graphify, Memobase, Memgraph, and MemPalace each expose a different slice of semantic capability — not as embeddings or heuristics, but as tools the agent can call.

All of them are open‑source MCP servers, which means their tool surfaces are transparent, inspectable, and directly usable in agent workflows. Individually, they solve different problems. Together, they form the beginnings of a semantic stack for agent‑native development.

Below is a detailed map of their tool surfaces — the actual verbs an agent gains when these servers are plugged in.

---

GitNexus — Structural and Historical Code Reasoning

GitNexus gives agents a deep, structural, and historical understanding of a codebase. It builds its model using Tree‑Sitter, extracting symbols, references, processes, and module boundaries, and then layers commit history and multi‑repo contract analysis on top. Its MCP surface is split into per‑repository tools and group‑level tools, giving agents both a maintainer’s view of a single repo and an architect’s view across many.

GitNexus MCP tools:

Per-repo tools:

• list_repos — discover all indexed repositories with metadata (paginated)
• query — process-grouped hybrid search (BM25 + semantic + RRF) grouped by execution flow
• context — 360-degree symbol view: categorized refs and process participation
• impact — blast radius analysis with depth grouping, confidence scoring, and risk classification
• detect_changes — git-diff impact: maps changed lines to affected processes and symbols
• rename — multi-file coordinated rename with graph + text search
• cypher — execute raw Cypher graph queries over the knowledge graph
• route_map — visualize execution routes across the codebase
• tool_map — map tools and their relationships within the graph
• shape_check — validate structural shape and consistency of the graph
• api_impact — blast radius analysis scoped to API boundaries

Group tools (multi-repo):

• group_list — list configured repository groups
• group_sync — extract contracts and match them across repos/services

GitNexus exposes 13 MCP tools (11 per-repo + 2 group tools) as of v1.6.5. The surface is actively growing. 1

GitNexus forms the structural and historical layer of the semantic stack. Its per‑repo tools give agents a maintainer’s view of how a system is wired and how it has changed, while its group‑level tools give them an architect’s view of how services interact, contract boundaries evolve, and execution flows span multiple repositories.

---

Codebase‑Memory‑MCP — Structural, Semantic, Temporal, Cross‑Service, and Indexer‑Aware Code Memory

Codebase‑Memory‑MCP exposes the broadest and most versatile tool surface in the ecosystem. Like GitNexus, it uses Tree‑Sitter to build a structural graph of the codebase — but it goes further by incorporating hybrid LSP signals and cross‑service communication detection.

The result is a semantic model that spans files, functions, services, protocols, and communication channels, all accessible through MCP tools.

Codebase‑Memory‑MCP MCP tools:

Indexing:

• index_repository — index a repository into the graph; auto-sync keeps it fresh after that
• list_projects — list all indexed projects with node/edge counts
• delete_project — remove a project and all its graph data
• index_status — check indexing status of a project

Querying:

• search_graph — structured search by label, name pattern, file pattern, and degree filters
• trace_path — BFS traversal of callers and callees, depth 1–5 (alias: trace_call_path)
• detect_changes — map git diff to affected symbols and blast radius with risk classification
• query_graph — execute read-only Cypher-like graph queries
• get_graph_schema — node/edge counts, relationship patterns, and property definitions per label
• get_code_snippet — read source code for a function by qualified name
• get_architecture — codebase overview: languages, packages, routes, hotspots, clusters, and ADR
• search_code — grep-like text search within indexed project files
• manage_adr — CRUD for Architecture Decision Records
• ingest_traces — ingest runtime traces to validate HTTP call edges

The MCP server exposes exactly 14 tools covering indexing, search, graph queries, tracing, architecture analysis, and ADR management. 2

Codebase‑Memory‑MCP forms the semantic substrate of the stack: search, structure, time, cross‑service communication, architecture decisions, runtime traces, and index lifecycle — all exposed as tools. Tree‑Sitter provides structural grounding, hybrid LSP signals refine accuracy through language-server-grade type resolution, and cross‑service detection lets agents treat a distributed system as a single, queryable semantic graph.

---

Graphify — Concept Graphs for Domain Knowledge

Graphify builds a queryable knowledge graph from a codebase and associated content, then exposes that graph as MCP tools. Its tool set covers graph traversal, querying, community inspection, and structural analysis.

Graphify MCP tools:

• query_graph — BFS/DFS search over the knowledge graph; returns relevant nodes and edges as text context
• get_node — retrieve full details for a specific node by label or ID
• get_neighbors — retrieve all direct neighbors of a node with edge details
• get_community — get all nodes in a community by community ID
• god_nodes — return the most connected nodes — the core abstractions of the knowledge graph
• graph_stats — return summary statistics: node count, edge count, communities, and confidence breakdown
• shortest_path — find the shortest path between two concepts in the knowledge graph

These tools are exposed via the MCP server (graphify <path> --mcp). 3

Graphify gives agents semantic search, node inspection, neighbour traversal, community exploration, centrality analysis, and shortest-path queries over the knowledge graph.

Graphify forms the conceptual layer of the semantic stack, giving agents graph traversal over domain knowledge and code concepts.

---

Memobase — Application Memory

Memobase is a user identity and profile memory layer for applications, designed for agents that need durable state without cognitive complexity.

What makes Memobase distinctive is that it implements user profile‑based memory.

User profile‑based memory models each user as a persistent, evolving profile, rather than a collection of isolated memory entries. Instead of storing disconnected facts, it builds a structured representation of preferences, behaviors, feedback, and historical interactions over time, tied to a specific user identity.

In practice, this means the agent doesn’t just remember what happened, but maintains a view of:

who this user is, and how they evolve

Memobase MCP tools:

• save_memory — store data in long-term memory
• search_memories — retrieve relevant memories via semantic search
• get_user_profiles — retrieve structured user profile information

The Memobase MCP server exposes exactly three tools.

Memobase forms the application memory layer of the semantic stack — lightweight, open‑source, and focused on durable state rather than cognition. It gives agents a simple, reliable substrate for persisting information across interactions without the overhead of a full semantic or temporal memory system.

---

Memgraph — Project Memory and Structural Substrate

Memgraph occupies a different role from the MCP servers above.

Unlike Memobase, which models users over time, Memgraph models systems as graphs of relationships.

At its core, Memgraph is:

• a persistent graph database, and
• an MCP-compatible tool provider via the Memgraph AI Toolkit

This distinction is fundamental:

• Memobase answers:

  Who is this user? What do they prefer? How have they evolved?

• Memgraph answers:

  How is this graph structured? Which nodes are most central? What is semantically similar to this node?

Instead of storing isolated entries, Memgraph represents knowledge as connected entities and relationships, making structure explicit and directly queryable. This enables agents to reason about dependencies, impact, and system behavior through deterministic graph traversal rather than indirect retrieval.

Through the Memgraph AI Toolkit, Memgraph exposes a unified set of tools for querying and analyzing graph data:

• list_databases — list all available databases
• use_database — switch the active database context
• run_query — execute any Cypher query against the Memgraph database (read-only by default)
• get_schema — fetch graph schema: labels, relationships, and property keys
• get_configuration — fetch current Memgraph configuration settings
• get_index — retrieve information about existing indexes
• get_constraint — retrieve information about existing constraints
• get_storage — retrieve storage usage metrics for nodes, relationships, and properties
• get_triggers — list all database triggers
• get_procedures — list all available Memgraph procedures and MAGE graph algorithm modules
• get_page_rank — compute PageRank scores for all nodes
• get_betweenness_centrality — compute betweenness centrality on the entire graph
• get_node_neighborhood — find nodes within a specified distance from a given node
• search_node_vectors — perform vector similarity search on nodes using cosine similarity

Memgraph forms the graph analytics and query layer of the semantic stack — a persistent graph database where agents can run arbitrary Cypher queries, inspect schema and indexes, compute PageRank and betweenness centrality, invoke MAGE graph algorithm modules, and perform vector similarity search over node embeddings alongside standard neighbourhood traversal.

---

MemPalace — Cognitive Memory and Temporal Reasoning

MemPalace exposes the richest cognitive memory surface in the MCP ecosystem. It is designed for agents that need identity, continuity, temporal reasoning, and the ability to evolve their own internal knowledge over time. Its toolset spans episodic memory, semantic memory, associations, timelines, metadata, lifecycle operations, and advanced retrieval.

MCP Tools (33 tools)

Palace — Read

• mempalace_status — palace overview: total drawers, wing and room counts, AAAK spec, and memory protocol
• mempalace_list_wings — list all wings with drawer counts
• mempalace_list_rooms — list rooms within a wing, or all rooms if no wing is given
• mempalace_get_taxonomy — full wing → room → drawer count tree
• mempalace_search — semantic search returning verbatim drawer content with similarity scores
• mempalace_check_duplicate — detect similar existing entries before filing
• mempalace_get_aaak_spec — retrieve the AAAK encoding specification

Palace — Write

• mempalace_add_drawer — file verbatim content into the palace
• mempalace_delete_drawer — delete a memory entry by ID (irreversible)
• mempalace_get_drawer — fetch a single drawer by ID with full content and metadata
• mempalace_list_drawers — list drawers with pagination and optional wing/room filter
• mempalace_update_drawer — update an existing drawer’s content, wing, or room
• mempalace_mine — mine a directory into the palace (MCP equivalent of the mempalace mine CLI)
• mempalace_sync — prune drawers whose source files are gitignored, deleted, or moved

Knowledge Graph

• mempalace_kg_query — query entity relationships with optional time filtering
• mempalace_kg_add — add a fact (subject–predicate–object triple) to the knowledge graph
• mempalace_kg_invalidate — mark a fact as no longer true
• mempalace_kg_timeline — chronological timeline of facts for an entity
• mempalace_kg_stats — knowledge graph overview: entities, triples, current and expired facts

Navigation

• mempalace_traverse — walk the palace graph from a room across wings
• mempalace_find_tunnels — find rooms that bridge two wings
• mempalace_graph_stats — palace graph overview: nodes, tunnels, edges, connectivity
• mempalace_create_tunnel — create a cross-wing tunnel linking two palace locations
• mempalace_list_tunnels — list all explicit cross-wing tunnels
• mempalace_delete_tunnel — delete an explicit tunnel by its ID
• mempalace_list_hallways — list within-wing hallway records (entity co-occurrence links)
• mempalace_delete_hallway — delete a hallway record by its ID
• mempalace_follow_tunnels — follow tunnels from a room to see what it connects to in other wings

Agent Diary

• mempalace_diary_write — write to the agent’s personal diary (each agent gets its own wing)
• mempalace_diary_read — read recent diary entries for an agent

System

• mempalace_hook_settings — get or set auto-save hook behaviour (silent save, desktop toast)
• mempalace_memories_filed_away — check whether a recent palace checkpoint was saved
• mempalace_reconnect — force a reconnect to the palace database after external modifications

The MemPalace MCP server exposes exactly 33 tools grouped by cognitive role, documented at mempalaceofficial.com/reference/mcp-tools.

MemPalace forms the cognitive layer of the semantic stack — the closest thing agents have to long‑term memory, continuity, and experience. Its tool surface spans spatial palace storage (read, write, sync), a temporally‑aware knowledge graph with fact invalidation and chronological timelines, cross‑wing navigation via tunnels and hallways, and a personal agent diary. Together they let agents not only remember facts, but organize them spatially, reason over how knowledge changes over time, and maintain a continuous record of their own activity.

---

The Semantic Stack, Defined Entirely by Tools

Each of these MCP servers covers a different dimension of software understanding:

• GitNexus captures structure and history
• Codebase‑Memory‑MCP captures semantics, services, and time
• Graphify captures concepts, domain knowledge, and PR analysis
• Memobase captures user identity and personalization
• Memgraph captures graph analytics, vector search, and structural queries
• MemPalace captures agent cognition and continuity

They are not competing approaches. They are complementary layers of the same emerging architecture.

A single project can — and often should — use several of them together. The right combination depends on the codebase, the domain, the workflows, and the level of autonomy you expect from your agents.

Taken together, they form the first real semantic stack for coding agents: a multi‑layered foundation where agents can reason about structure, meaning, history, concepts, memory, and time — not as text, but as tools.

The MCP surface is the architecture.