SDK Overview

The Memco SDKs give your own code the same memory operations that MCP gives an off-the-shelf agent. Use them when you are building the agent, the pipeline, or the product yourself and want memory as a component of it.

All three packages are open source under the MIT license at github.com/memcoai/memcoai. The Go module requires Go 1.25 or newer. You need a Memco account and an API key, created from the Memco dashboard.

SDK, MCP, or CLI?

MCP is the right choice when the agent already exists and you want it to use Memco: Claude, ChatGPT, Cursor, Claude Code, and any other MCP-compatible client. You configure a connection and the agent does the rest. See the MCP overview.

The SDK is the right choice when you own the code that drives the agent loop, or when there is no agent at all. Typical cases:

• An agent you built with LangChain, the Anthropic SDK, the OpenAI SDK, or your own loop, that should search memory before working and write back what it learned.
• A product you ship to your own customers, where memory is part of what the product does. See Embedding memory in your product.
• Data pipelines: seeding a memory network from existing documents, exporting it, or running evaluations against it.
• Administrative tooling and integrations that call the API without a model in the loop.

The CLI covers interactive and scripted use from a terminal. See CLI installation.

All three surfaces talk to the same service, with the same domains and the same operations. Which memory a call can reach is decided by the network permissions of the user it is made for, not by which surface made it: an MCP-connected engineer and an SDK-driven agent serving one of your customers see the networks they have each been granted, and nothing else.

What the SDKs provide

The SDKs wrap the Memco API with the same design, so a team working in more than one language finds the same shape on each side.

Every memory operation. list_domains, start_session, search, get_memory, create_memory, enrich_memory, share_feedback, revert_memory, and import_memories. These are the operations the MCP tools expose, with the same semantics.

Sessions that cannot be dropped. A session groups the searches made for one task, so they can be rated together and so the service can relate them. start_session returns a session object with every session-bound operation already applied. Once bound, no later call can omit the session id. This matters more than it looks: a search that silently drops the id is still a valid search, it just stops being part of the series, which is the kind of mistake an agent makes and nobody notices.

Agent tools in the service's own words. A session exports its operations as a toolset for LangChain, the Anthropic SDK, and the OpenAI SDK. The Go SDK exports Anthropic and OpenAI tool shapes; it has no LangChain adapter. The description a model reads for each tool comes from the same manifest the hosted MCP server publishes, so an agent built on the SDK is steered by the service's guidance rather than by wording that lives in the client. See Building an agent with the SDK.

Typed results and typed errors. Results are typed objects. Every failure is a subclass of a single base error (in Go, a concrete type implementing memcoai.Error, matched with errors.As), with specific classes for authentication, permission, invalid requests, rate limits, timeouts, and service availability, so no transport-level exception reaches your code.

Networks and users. A client authenticated as an API client manages your memory networks and the users of your product, and opens sessions that act for one of those users. See Embedding memory in your product.

Local validation. On connection the client fetches the input limits the service enforces and applies them locally. An oversized field is refused before a request is sent.

Idiomatic in each language. Python ships Memco and AsyncMemco with identical method names. Node.js is async throughout and supports await using for automatic cleanup, with ESM and CommonJS builds. Go takes a context.Context on every blocking call for cancellation and deadlines, and a client and its sessions are safe for concurrent use.

Quick start

Python

from memcoai import Memco

with Memco() as client:  # reads MEMCO_API_TOKEN
    session = client.memory.start_session("coding")

    result = session.search("how should a client authenticate against the memory API")
    for memory in result.memories:
        for insight in memory.insights:
            print(insight.title, insight.updated)

Node.js

import { Memco } from '@memco/memcoai'

await using client = await new Memco().connect() // reads MEMCO_API_TOKEN
const session = await client.memory.withSession('coding')

const result = await session.search(
  'how should a client authenticate against the memory API'
)
for (const memory of result.memories) {
  for (const insight of memory.insights) {
    console.log(insight.title, insight.updated)
  }
}

Go

ctx := context.Background()
client, err := memcoai.NewClient(memcoai.Options{}) // reads MEMCO_API_TOKEN
if err != nil {
	return err
}
defer client.Close(ctx)
if err := client.Connect(ctx); err != nil {
	return err
}
session, err := client.Memory.StartSession(ctx, "coding")
if err != nil {
	return err
}

result, err := session.Search(ctx, "how should a client authenticate against the memory API", memcoai.ScopedSearchParams{})
if err != nil {
	return err
}
for _, memory := range result.Memories {
	for _, insight := range memory.Insights {
		fmt.Println(insight.Title, insight.Updated)
	}
}

Configuration

All three SDKs read their configuration from the environment, with constructor arguments (in Go, memcoai.Options fields) taking precedence.

The credential is a Memco API key from the dashboard. MEMCO_API_KEY is still honored but logs a warning; switch to MEMCO_API_TOKEN.

An API client's id and secret are used together, and the SDK exchanges them for a token that it renews for as long as the client is open. When both a token and client credentials are set in the environment, the client credentials win. A client authenticated this way manages networks and users, and reaches memory through sessions that act for the users of your product; see Embedding memory in your product.

Runnable examples

Each package ships a set of runnable programs, smallest first: connect and search, the full search-and-rate loop, contributing and reverting, bulk import, error handling, concurrent searches, mapping a customer's organization into networks and users, acting for the users of your product, and a complete LangChain agent.

• Python examples
• Node.js examples
• Go examples (a complete Anthropic SDK agent in place of LangChain)

Versioning

The reference documentation is published per version. /sdk/python/latest, /sdk/nodejs/latest, and /sdk/go/latest always point at the current release; earlier releases stay available at their own version paths. Each package records the version of the service contract it was built from, and the service tells a client when the version it is running is superseded.

Next steps

• Building an agent with the SDK — the learning loop, the toolset export, and the patterns that make memory work in an agent you control
• Embedding memory in your product — memory networks, the users of your product, and how memory becomes part of what you ship
• Python reference, Node.js reference, and Go reference
• Learning on the Job — a measured example of an agent learning from reviewer corrections