Your agents don't have to be Claude Code or Cursor for this to work

If your agent can be an MCP client, it already works

• MCP is a wire protocol, not a framework lock-in. Most in-house agent stacks are built around a plain LLM API call loop. Adding MCP support to a loop like that is typically a small, self-contained client — the same effort as adding any other tool-calling capability, and something a growing number of internal frameworks already have, given how many public frameworks (Claude Code, Cursor, LangGraph, Microsoft Agent Framework) ship one already.
• The config shape doesn't change. Every MCP client we've seen — public or internal — ultimately needs the same three things: a command to launch the server, its arguments, and an environment block for credentials. That's it.
• We'll help with the rest. If your setup is unusual enough that wiring in an MCP client isn't obvious — a proprietary transport, an internal gateway that mediates tool calls, a compliance requirement around how credentials get passed — email founders@threadctx.dev and we'll work through it with you. Custom integration support is available for Team plan customers who need it.

The config, if you need a starting point

This is the exact block Claude Code and Cursor use. If your internal client reads config the same way (command + args + env), this is very likely all you need.

{
  "mcpServers": {
    "threadctx": {
      "command": "npx",
      "args": ["-y", "threadctx-mcp"],
      "env": {
        "THREADCTX_MODE": "cloud",
        "THREADCTX_API_KEY": "tctx_..."
      }
    }
  }
}

Two tools once connected: memory_write(content, tags?) and memory_query(task_description, max_results?). See what an MCP server is if your team is new to the protocol.