MCP integration

Give your MCP client a shared memory.

Connect your agent to current records it can read and updates it can propose. The hosted MCP endpoint gives compatible clients tools for retrieval, consolidation, and change history under your workspace rules.

Start free See an example

An agent memory loopExample

Read the record before acting. Propose what changed.

Before a task: memory_get loads the relevant entity.
When context is missing: memory_search or memory_traverse finds related information.
After new information: memory_insert submits an observation.
When a change needs explanation: memory_history retrieves the entity changelog.

Illustrative tool sequence. The client decides which tools to call; workspace policy governs incoming observations.

In practice

What a client sends. What comes back.

Each step is one tools/call request with a tool name and its arguments. The client reads the schema before it writes, so it proposes fields the workspace already declares, then reads the record back.

01ontology_list

Learn the vocabulary first: the declared classes and fields, their allowed values, and which constraints are enforced.

Call

{
  "name": "ontology_list",
  "arguments": {}
}

Result

# Ontology Schema

Mode: Free. Agents may propose schema changes.

## Customer
Open world: non-conforming writes are applied and reported as warnings.
Policy: supersede / deterministic / internal / auto_apply

| Predicate | Type | Cardinality | Required | Allowed values | Enforced | Declared on |
|---|---|---|---|---|---|---|
| city | string | single | no | - | no | Customer |
| plan | string | single | no | "starter", "growth", "scale" | yes | Customer |
| preferred_channel | string | single | no | "email", "phone", "sms" | no | Customer |

Schema revision: dbc8b1a4eddb449e64eabdc787f274fe

02memory_insert

Propose the update with the declared field names. The receipt says what changed: Lisbon supersedes Berlin, which the CRM sync recorded at 10:32, and the channel is added.

Call

{
  "name": "memory_insert",
  "arguments": {
    "entityType": "Customer",
    "entityRef": "customer:crm_1042",
    "data": { "city": "Lisbon", "preferred_channel": "email" },
    "source": "support-thread",
    "confidence": 0.97
  }
}

Result

Entity: customer:crm_1042
  - Superseded "city": "Berlin" → "Lisbon"
  - Asserted "preferred_channel" = "email"

03memory_get

Read the record back. The compact-v2 profile returns current facts and leaves out default values to keep the response small.

Call

{
  "name": "memory_get",
  "arguments": {
    "entity": "customer:crm_1042",
    "profile": "compact-v2"
  }
}

Result · shortened

{
  "ok": true,
  "profile": "compact-v2",
  "scope": { "facts": "current", "history": "not_loaded" },
  "results": [
    {
      "status": "found",
      "entity": { "canonicalId": "customer:crm_1042", "entityType": "Customer" },
      "facts": [
        { "predicate": "city", "value": "Lisbon", "confidence": 0.97 },
        { "predicate": "plan", "value": "growth", "confidence": 0.9 },
        { "predicate": "preferred_channel", "value": "email", "confidence": 0.97 }
      ]
    }
  ]
}

Calls and results from the ConceptMem MCP tools on a new database, after a CRM sync recorded the customer. Each call shows the name and arguments of a tools/call request; each result is the tool’s text content. The same result also arrives as structuredContent, described by the tool’s outputSchema.

Built into the workflow

Context before the task. Accountable updates after it.

Retrieve focused context

Load current facts for a known entity, search text, or follow relationships. Request evidence and history when you need to explain the answer.

Propose changes under your rules

Each observation carries provenance and follows the same consolidation and ontology checks as a REST or console write.

Inspect what happened

Read applied operations, skipped writes, and violations in the tool result. Authorized reviewers can decide proposals held by policy.

Tool reference

Tools for your memory workflow.

memory_insert

Propose updates with their provenance.

memory_operation

Recover confirmed receipts from a write plan.

memory_search

Find current records by text.

memory_get

Read an entity’s current facts and relationships.

memory_history

Inspect an entity’s change history.

memory_traverse

Follow typed relationships between entities.

memory_validate

Check a proposed update before writing.

ontology_preview

Check a proposed schema change before applying it.

ontology_define

Propose entity types, fields, and relationship definitions.

ontology_list

Read the shared vocabulary and its constraints.

memory_export

Export a derived view of current records.

memory_retract

Retract a current fact or relationship.

memory_review

Approve or reject a proposal held for review.

One endpoint for your workspace.

Create a workspace access key, then copy the endpoint and client configuration from Connections. Follow the MCP guide to test a write, read the current record, and inspect its history.

Read the MCP documentation

Common questions

MCP, answered.

Didn’t find your answer?Ask the team Read the documentation

What is the ConceptMem MCP server?

It is a hosted Model Context Protocol endpoint for your workspace. A compatible client can read current records, propose and validate updates, inspect history, follow relationships, export views, and work with schema proposals or reviews according to its permissions.

Which clients can use it?

Use a client that supports Streamable HTTP and the required authentication. Your workspace’s Connections page shows the endpoint and headers to configure with an access key.

Are MCP writes governed the same way?

Yes. memory_insert submits an observation that passes through consolidation with ontology validation and provenance, exactly like a write from the console or the SDK.

How should an agent use the tools in a task?

Load the relevant record before acting. Search or follow relationships for more context, then propose an update when new information arrives. Inspect the write result to see what was applied, skipped, or held. Use the changelog to explain accepted changes.

Does the agent need to know the schema first?

Use ontology_list to learn declared types, fields, relationships, and constraints, including inherited definitions and fields already in use. Reusing that vocabulary helps agents write to the same records and fields.

Keep exploring

Explore how the record works.

01 — Ontology

Start with one shared record

Give your next agent
the current record.

Create a database on the free plan, connect an agent over MCP or REST, and propose your first update.

Start free See how it works

Give your MCP client a shared memory.

Read the record before acting. Propose what changed.

What a client sends. What comes back.

Context before the task. Accountable updates after it.

Retrieve focused context

Propose changes under your rules

Inspect what happened

Tools for your memory workflow.

One endpoint for your workspace.

MCP, answered.

Explore how the record works.

Ontology

Consolidation

Retrieval

Give your next agent
the current record.

Give your MCP client a shared memory.

Read the record before acting. Propose what changed.

What a client sends. What comes back.

Context before the task. Accountable updates after it.

Retrieve focused context

Propose changes under your rules

Inspect what happened

Tools for your memory workflow.

One endpoint for your workspace.

MCP, answered.

Explore how the record works.

Ontology

Consolidation

Retrieval

Give your next agentthe current record.

Give your next agent
the current record.