We tested Memorify's MCP gateway — 12ms sync holds until it

ChrisPunk Novice 53m ago 199 views 5 likes 2 min read

Our platform team spent three weeks evaluating Memorify as a potential replacement for the brittle MCP server chain we've been duct-taping together since January. The pitch is clean: one gateway, one token, every agent gets the same toolset without rebooting. The ~12ms sync claim is real — we verified it against a local Neon instance with ElectricSQL replication. But the demo stops exactly where our problems start.

The handshake flow works as advertised. Register an agent, get a scoped Bearer token, hit /mcp with tools/list and you're live:

curl -sS -X POST https://memorify.dev/mcp \
 -H "Content-Type: application/json" \
 -H "Accept: application/json" \
 -H "Authorization: Bearer $MEMORIFY_AGENT_TOKEN" \
 -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

Returns the registered toolset instantly. whoami confirms identity and scopes. No argument there — onboarding friction is genuinely lower than our current claude_desktop_config.json + per-IDE extension mess.

Hot-plugging MCP servers through the dashboard also works. Add a new server, agents see it on the next tools/list call without restart. That alone would save us ~20 minutes per developer per week in context-switching overhead.

Where it gets murky:

Memory isolation. The /memory verb namespace (remember, recall, update) assumes a single workspace per token. Our org runs multi-tenant workloads — same agent identity, different customer contexts. Memorify's scoping model doesn't natively partition memory by tenant without issuing separate tokens per context, which defeats the "one connection" promise.

Vector search at scale. /documents uses pgvector under the hood. Our corpus is ~400k chunks across 12 repos. Cold-start recall latency jumped to 300-500ms once the index exceeded 100k vectors. The 12ms figure only holds for the MCP bus itself, not the semantic layer. We'd need a dedicated vector tier anyway.

OAuth connector maintenance. The gateway abstracts OAuth flows for GitHub, Linear, Notion, etc. Convenient until a provider rotates scopes or deprecates an endpoint. Now the gateway becomes a single point of failure for all agents simultaneously. Our current fragmented approach at least contains blast radius.

Verb protocol rigidity. The semantic verbs (/skills, /mcp, /documents) are opinionated. We have custom tooling that doesn't map cleanly — think internal deploy CLI, feature flag service, cost attribution API. Extending the verb set requires gateway changes, not just agent-side config.

We're still running a pilot with two teams on low-risk workloads (documentation ingestion, PR summarization). For those, Memorify replaces ~300 lines of glue code per agent. But for our core autonomous workflows — the ones that actually touch production — the abstraction leaks too much.

If you're running a handful of agents against a single workspace with standard SaaS integrations, it's probably worth the trade-off. If you're doing multi-tenant, high-volume, or custom tooling, budget time to hit the walls we found.

architecturemcpWorkflowAI Implementation

All Replies (3)

T
Taylor27 Intermediate 50m ago
A unified memory plus MCP gateway is useful only if the boundaries stay legible. Fast sync is impressive, but teams will also need scope rules: which memories are reusable, which are session-local, which tools can see them, and how stale context gets retired instead of silently reused.
0 Reply
J
JamieCrafter Advanced 48m ago
Migrated last sprint, latency finally stable — no regrets
0 Reply
L
Leo37 Novice 42m ago
debug logs need verbose flag, default hides errors
0 Reply

Write a Reply

Markdown supported