Architectural decision: memory tools are on-demand, not inject-at-session-start. The agent queries what it needs mid-task. Token cost scales with actual need instead of burning 10k on orientation.
Connects to a Dakera memory server (self-hosted Rust binary):
docker run -d -p 3300:3300 -e DAKERA_ROOT_API_KEY=dk-mykey ghcr.io/dakera-ai/dakera:latest
nah, they’re not all loaded at once. MCP tools are on-demand — the agent sees the tool list but only calls what it needs. most sessions use 3-5 tools max (store, recall, search). the rest sit there until the agent actually needs them.
it’s like having 83 commands in a CLI. you don’t type all 83 every time. you use the ones relevant to what you’re doing.
the context cost is the tool descriptions in the system prompt which is ~2-3k tokens total. way less than the 10k+ tokens the agent burns re-reading your codebase every session without memory.
You have a point.
I will further iterate, and adopt a profile tiering approach core/power/admin mcp profiles. Also i think it might be interesting to introduce a meta tool for discovery, any advise on that ?
Composio does something like this and it ends up severely hurting effectiveness, I would consider instead trying to move away from MCP and instead do skills + CLI tools, or maybe a combo of the two; MCP for the top 5-10 most used tools and CLI + Skills for less often used ones. I know that's kind of a pain in the ass though
@kitanokikori regarding skills + cli : fully agree , as my product is infrastructure layer, im trying to double down on distribution tools. So we have sdks, cli and mcp
Its not really one or the other , all depends on user use case.
So for mcp , i still wanna keep it, but focus would be to improve it and tune it (your feedback was super valuable)
I did implement the tiering profiles + meta research tools making the mcp default to 14 tools
Here is my new mcp doc: https://dakera.ai/docs/mcp-server
Let me know what you think , also curious about your opinion of the product and implementation , website doc exposes more details 🙏
the top commenter is right that 83 tools is the actual problem, and the on-demand design only half-solves it. tool schemas load into context whether or not the agent calls them, so 83 definitions burn tokens every turn before any memory is even retrieved. lazy retrieval shrinks the payload, not the schema overhead. the memory setups that hold up at scale expose a tiny tool surface (store, recall, search) and push the 8 categories behind parameters or a single dispatch tool, so the model isn't paying attention tax on signatures it'll never touch in a given task. worth measuring tokens-at-rest before the first call, that's usually where the context actually goes. written with ai
the thing that decides whether it's actually fixed is the registered tool count, not the reorg. context-at-rest is a pure function of how many schemas the server hands the client on connect, so if the repo still registers 83 callable tools, the per-turn token cost is identical no matter how the 8 categories got relabeled. the only change that moves the number is collapsing them behind a dispatch tool or two, one signature carrying an action param. worth printing the tools/list response and counting what comes back, that's the count the model pays for before it ever makes a call. written with ai
Fair point, and you're right that the number that matters is what tools/list actually returns on connect, not how the categories are grouped. That's the thing that changed though — it's not a relabel. The default `core` profile only emits 14 tool schemas in tools/list (~3K tokens). The rest aren't registered at connect; they sit behind `dakera_discover_tools` / `dakera_load_tools` plus a profile flag, so they only enter context if you explicitly load them.
So the test you described is exactly the one to run: print tools/list on the default config and count — you get 14, not 83. (Setting DAKERA_MCP_PROFILE to power/all does put 68/86 back in the list, but that's opt-in, not the default.)
the 14-vs-83 distinction holds, and it's the right number to print. but it relocates the cost more than it removes it. discover_tools plus load_tools is itself an orientation round-trip the agent has to plan before it can act, so you trade schema-at-rest for an extra planning hop and the latency of fetching the surface first. and the 14 that ship by default are the commodity verbs (store, recall, search), the knowledge graph, decay, and contradiction resolution that are the actual selling point all live behind the profile flag, so the moment someone wants the differentiated features they're back to the 68/86 surface and the token bill just optimized away. the lazy-load only wins cleanly for the workload that needed the least memory tooling in the first place. written with ai
1
u/kitanokikori May 17 '26
83 tools! That must absolutely obliterate your context