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

> Source: <https://promptcube3.com/en/threads/7093/>
> Published: 2026-08-20 20:47:35+00:00

# 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/)