MCP tools reference
The tools the apiary exposes over MCP: memory_search, memory_store, honeycomb_read, the codebase cluster, and how they show up as native tools in your assistant.
The apiary runs an MCP server so coding assistants that speak the Model Context Protocol get memory tools like memory_search and memory_store directly in their native tool list. Every tool is a thin client of the local daemon, which does the real work and never exposes secret values.
What is the MCP server and do I have to set it up separately?
It is a Model Context Protocol server that the apiary runs so assistants that speak MCP can call memory tools directly. It gets registered automatically when you connect an assistant with honeycomb setup, there is no separate add-a-server step.
What is the difference between a search tool and a read tool?
Read and resolve tools, like memory_get and honeycomb_read, are deterministic lookups that return exactly the row asked for. Search and mine tools, like memory_search, run hybrid recall across many rows and rank the results by relevance.
Can an assistant read my secret values through MCP?
No. The secrets tools are value-safe by design, an assistant can list secret names and cause a secret to be used, but there is no tool, on MCP or any other surface, that returns a secret's actual value.
The apiary runs a Model Context Protocol (MCP) server so that coding assistants which speak MCP can ask for memory and codebase operations explicitly, as native tools in their own tool list. The server is registered automatically during honeycomb setup, there is no separate "add an MCP server" step.
#What is the MCP server and do I have to set it up separately?
Every tool handler is a thin client of the local daemon (default 127.0.0.1:3850), the tool states what it wants, and the daemon does the real work. It gets wired in automatically when you connect a supported assistant, so once you have run honeycomb setup, the tools are simply available.
#What tools are available?
| Tool | Purpose |
|---|---|
memory_search |
Hybrid recall (words plus meaning) over memory, ranked by relevance |
memory_store |
Write a memory, the explicit "remember this" tool |
memory_get |
Resolve a single memory by its id or path, no ranking |
memory_list |
List memories within the caller's scope |
memory_modify |
Change an existing memory, requires a reason |
memory_forget |
Remove a memory from recall, requires a reason |
honeycomb_search |
Search the memory browse surface for matching paths and snippets |
honeycomb_read |
Read the content at a specific memory path |
honeycomb_index |
List an orientation index of recent summaries and sessions |
honeycomb_code_search |
Find symbols by name or pattern in the codebase graph |
honeycomb_code_context |
Return a symbol's detail plus its immediate neighbors |
honeycomb_code_blast |
Return everything that depends on a symbol |
honeycomb_code_impact |
Report the impact of changing a symbol |
honeycomb_goal_add |
Create a goal surfaced in agent context |
secret_list |
List the names of stored secrets, never values |
secret_exec |
Run a command with named secrets injected into its environment |
#What is the difference between a search tool and a read tool?
The tool surface splits along a clear seam. Read and resolve tools, like memory_get and honeycomb_read, are deterministic lookups, they return exactly the row asked for and do not rank anything. Search and mine tools, like memory_search and honeycomb_search, run hybrid recall, both exact words and meaning, fused into one ranked result set, with an honest degraded flag when the meaning-based path was not available for that query.
#How does the memory cluster work?
memory_store writes a memory through the daemon, and storing the same content twice returns the existing memory instead of creating a duplicate. memory_search is the cold-query tool, reach for it when you do not already hold a reference to what you want. memory_get and memory_list are for when you already know what you are looking for. memory_modify and memory_forget both require a reason argument, because every change to a memory is audited, and forgetting is a soft delete rather than a hard one, so the audit trail survives.
#How does the codebase cluster work?
Once a codebase graph exists for your project, four tools let an assistant query it: search for a symbol, get its detail and neighbors, find everything that depends on it, or check the impact of changing it. These read a local snapshot built with tree-sitter, no network call and no model involved, so a symbol reading "zero dependents" is a fact about that snapshot, not proof the code is dead, and a snapshot older than your latest edits should be treated as slightly stale.
#Can an assistant read my secret values through MCP?
No. secret_list returns names only, and secret_exec runs a command with the named secrets injected into its environment without ever exposing their values to the caller, output comes back with any secret value replaced by a redaction marker. There is no tool, on MCP or any other surface, that hands back a secret's actual value.
#Which tools write, and which are read-only?
Read-only: memory_search, memory_get, memory_list, honeycomb_search, honeycomb_read, honeycomb_index, all four codebase tools, and secret_list.
Write: memory_store, memory_modify, memory_forget, honeycomb_goal_add.
Runs a process, not a memory write: secret_exec.
#Common questions
#What is the MCP server and do I have to set it up separately?
It is a Model Context Protocol server that the apiary runs so assistants that speak MCP can call memory tools directly. It gets registered automatically when you connect an assistant with honeycomb setup, there is no separate add-a-server step.
#What is the difference between a search tool and a read tool?
Read and resolve tools, like memory_get and honeycomb_read, are deterministic lookups that return exactly the row asked for. Search and mine tools, like memory_search, run hybrid recall across many rows and rank the results by relevance.
#Can an assistant read my secret values through MCP?
No. The secrets tools are value-safe by design, an assistant can list secret names and cause a secret to be used, but there is no tool, on MCP or any other surface, that returns a secret's actual value.