slm-profile

Files (1)

• SKILL.md

SKILL.md (first lines)

# slm-profile — Memory Profiles and Tool Sets

Two different things are called "profile" in SuperLocalMemory. Keep them apart.

- A **memory profile** is a namespace inside one store. It has its own memories,
  knowledge graph, learned patterns, retention settings and audit trail. A fresh
  install has one, called `default`. This is what `switch_profile`,
  `slm profile` and the `profile_id` argument are about.
- An **MCP tool set** (`SLM_MCP_PROFILE`: `core`, `code`, `full`, `power`,
  `mesh`) decides which tools the server shows your host. `switch_profile` does
  not change it.

A memory profile organises memory. It is not a security boundary: any local
caller that can name a profile can read it, unless the user has turned on company
mode with roles. For memories that must be unreachable from another bot or user,
use a separate data directory (`SLM_DATA_DIR`) or company mode (`slm-governance`).

---

## Memory profiles

```bash
slm profile list [--json]
slm profile create <name> [--json]
slm profile switch <name> [--json]
slm status --json          # data.profile is the active profile
```

Creating a profile is a CLI action; there is no MCP tool for it. Over MCP:

```
switch_profile(
  profile_id: str,   # the name of an existing profile
)
```

`switch_profile` changes the **active profile**. The change is not private to
your session: it is written as the machine's active profile, so every later call
from every session on this machine, and the dashboard, now work in it until
someone switches again. An unknown name is refused (`Profile '<name>' does not
exist`); nothing is created. In company mode it also needs a role on the target
profile. Only switch when the user asks to move; do not switch to peek at
something.

### Reaching another profile for one call

Most tools take an optional `profile_id`: `remember`, `recall`, `search`,
`fetch`, `list_recent`, `update_memory`, `delete_memory`, `session_init`,
`close_session`, `report_outcome`, `report_feedback`, `get_status`,
`get_memory_summary`, the correction and memory-kind tools, and others. A
non-empty value serves that one call from that profile (which must already
exist) and **never moves the active profile**. An empty value means the active
profile. Prefer this to switching and switching back.

```
recall(query="rollout plan", profile_id="work", session_id="<sid>")
remember(content="...", tags="ops", profile_id="client-acme")
```

`forget` and the mesh tools take no `profile_id`; they act on the active profile.

### What a profile isolates

- `recall` returns only the profile's own memories, plus shared or global ones
  only when you opt in (see `slm-scope`).
- `remember` writes to the profile you name or the active one.
- The code graph is not partitioned by profile: it lives in `code_graph.db` in the data directory.
- The `slm_cache_*` key-value cache and `slm_compress` recovery store are keyed
  by the calling agent, not by profile, so switching profiles does not give you
  a clean cache (see `slm-cache`).

### Separate stores

To keep two bots or two clients completely apart, give each its own
`SLM_DATA_DIR` in its MCP config. You can run several SLM MCP servers at once,
named differently (for example `superlocalmemory-personal` and
`superlocalmemory-work`), each pointed at its own directory.

---

## MCP tool sets

| Profile | Tools | What it is |
|---------|-------|------------|
| `core` | 19 tools — remember, recall, search, fetch, expand, list_recent, update_memory, forget, session, optimize, corrections, summaries, switch_profile | Smallest set |
| `code` | 39 tools — core + portable Brain evidence, report_outcome/report_feedback, 6 code-graph tools, memory kinds, bounded loops | For coding agents that need the graph; no mesh, no `get_status` |
| `full` | 58 tools (5 more while images are on) — everyday memory, delete_memory, get_status, observe, saved views, learning tools, skills, optimize, kinds, loops, mesh | The default for every app |
| `power` | 70 tools — full + audit_trail, retention, compaction, consistency_check, behavioral and diagnostic tools | Governance and admin work |
| `mesh` | 9 tools — mesh coordination only | Lightweight cross-session signalling |

Every app gets the 58-tool `full` set unless the user chose another: no plugin
or extension SuperLocalMemory ships sets one. It fits hosts that cap the total
number of MCP tools at about 100. While pictures
and documents are on (`slm media status`), `full` lists 62 tools and `power` 74:
the five picture tools `remember_media`, `get_media`, `remember_document`,
`media_status` and `media_upload_link` are added to both, and never to `core`,
`code` or `mesh` (see `slm-media`). The server reads this when it starts. Two
more environment variables widen or narrow it: `SLM_MCP_ALL_TOOLS=1` registers
every tool (110), and `SLM_MCP_TOOLS=remember,recall,...` registers exactly the names
listed. `SLM_MCP_PROFILE=whole` is also every tool. The code-graph tools beyond
the six in `code` (such as `update_code_graph`, `list_graph_stats`) and tools
such as `core_memory` and `settle_session_outcomes` exist only with
`SLM_MCP_ALL_TOOLS=1`, `whole` or an explicit `SLM_MCP_TOOLS` list. Tools whose
function is to manage the SLM computer are never available to a remote caller.

The tool set is read when the MCP server starts. To change it for every app at
once, the user runs one command and then restarts their apps (or reconnects
them in Dashboard → Connected apps); asking the server at runtime does not work:

```bash
slm tools                 # the current set and how many tools each set has
slm tools set power       # core, code, full, power, mesh or whole
slm tools set default     # back to full
```

An app whose own MCP config sets `SLM_MCP_PROFILE` keeps that value: it wins
over the saved choice, for that app only (`slm connect <ide> --profile <name>`
writes it). Setting `SLM_MCP_PROFILE` to a name that does not exist stops
`slm mcp` with a message listing the valid names. Older count-suffixed names

From qualixar/superlocalmemory, AGPL-3.0.

More from qualixar/superlocalmemory