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

Memorify's MCP gateway delivers a verified 12ms sync for agent tool registration, but multi-tenant memory isolation, vector search latency beyond 100k vectors, and rigid verb protocols limit its use for complex workloads, according to a hands-on test by an unnamed engineering team. The gateway replaces ~300 lines of glue code per agent for simple use cases, but the team reports cold-start recall latency of 300-500ms and a single point of failure for OAuth connectors.

We tested Memorify's MCP gateway — 12ms sync holds until it MCP /en/tags/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. Next Testing Three Agent Frameworks on A2A — What Broke and What → /en/threads/7071/