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.