TeamShared

memory_remember

Write a durable memory into the caller's org.

fact / preference / note / outreach -> semantic pillar. event -> episodic. procedure / skill -> rejected; use memory_procedure_set / memory_skill_set. Routed through the guarded ingestion pipeline (PII, injection screening, near-dupe merge / contradiction supersede) under RLS. When repo / github are given the memory is tagged repo:<slug> / github:<owner>/<repo>. namespace= (or the default from those args) is an org-allowlisted container — recall with the same slug excludes other namespaces. paths= tags the repo files the memory is about (memory_for_paths reads them). Result includes org + bound (alias session_bound). bound is the MCP org-session overlay, not GitHub: false on a normal /mcp session still writes to the token's org.

Input Schema

Name	Required	Description	Default
`kind`	No	fact, preference, event, note, or outreach (not procedure/skill)	note
`repo`	No	Workspace slug of the repo this memory belongs to (e.g. the slug used for memory_state). For code/repo-specific work, pass your current workspace slug so the memory is scoped to this repo (stored as a 'repo:<slug>' tag) and ranks higher when recalled from the same repo. Omit for cross-cutting memories.
`tags`	No	Optional free-form tags
`agent`	No	Override agent identity (defaults to bearer-token identity)
`paths`	No	Repo-relative POSIX file paths this memory is about (e.g. ['src/foo.ts']). Each is stored as a 'path:<p>' tag so memory_for_paths finds it. Absolute paths and '..' escapes are rejected; backslashes and './' are normalized.
`github`	No	GitHub repository as owner/repo (e.g. teamshared-ai/teamshared). Stored as a 'github:<owner>/<repo>' tag for cross-machine association; use with or instead of workspace repo= when the same GitHub repo is checked out at different paths.
`content`	Yes	Free-form text to remember
`subject`	No	Optional subject/entity this memory is about
`namespace`	No	Org-allowlisted container (repo:owner/name, github:owner/repo, or project:name). Tags this write. Omitted: default from github= then repo=. Invalid slugs fail. First write creates the slug on the org allowlist.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 28, 2026

addedInput schema / properties / paths

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "maxItems": 20,
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Repo-relative POSIX file paths this memory is about (e.g. ['src/foo.ts']). Each is stored as a 'path:<p>' tag so memory_for_paths finds it. Absolute paths and '..' escapes are rejected; backslashes and './' are normalized."
+}

Changed1 schema field changedSep 16, 2026

addedInput schema / properties / namespace

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Org-allowlisted container (repo:owner/name, github:owner/repo, or project:name). Tags this write. Omitted: default from github= then repo=. Invalid slugs fail. First write creates the slug on the org allowlist."
+}

Changed1 schema field changedSep 8, 2026

changedInput schema / properties / github / description

Previous value: -"GitHub repository as owner/repo (e.g. xhad/teamshared). Stored as a 'github:<owner>/<repo>' tag for cross-machine association; use with or instead of workspace repo= when the same GitHub repo is checked out at different paths."New value: +"GitHub repository as owner/repo (e.g. teamshared-ai/teamshared). Stored as a 'github:<owner>/<repo>' tag for cross-machine association; use with or instead of workspace repo= when the same GitHub repo is checked out at different paths."

Changed2 schema fields changedAug 30, 2026

changedInput schema / properties / kind / description

Previous value: -"fact, preference, event, or note (not procedure/skill)"New value: +"fact, preference, event, note, or outreach (not procedure/skill)"

changedInput schema / properties / kind / enum

Previous value: -[
-  "fact",
-  "preference",
-  "event",
-  "note",
-  "procedure",
-  "skill"
-]New value: +[
+  "fact",
+  "preference",
+  "event",
+  "note",
+  "procedure",
+  "skill",
+  "outreach"
+]

First observedAug 18, 2026

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations present, the description carries the full burden and does so: it discloses the guarded ingestion pipeline (PII, injection screening, near-dupe merge / contradiction supersede), RLS scoping, org-allowlist namespace rules including that the first write creates the slug, and that invalid slugs fail. It also pre-empts a likely misreading of the returned `bound` field (org-session overlay, not GitHub), which is exactly the kind of derivative behavior an agent would otherwise get wrong.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the write action, then type routing, then pipeline/scoping, then result semantics — a sensible information gradient. It is dense and backtick-heavy, and a few clauses (paths normalization, invalid-slug failure) duplicate the schema, costing a point but not readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter write tool with no annotations, the description covers the mutation's side effects, screening/supersede semantics, scoping containers, repo/GitHub tagging, and result interpretation; an output schema exists so return values needn't be spelled out further. Nothing essential to calling it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3 and the schema already documents kind, repo, github, paths, and namespace defaults ('default from github= then repo='). The description largely restates those (repo:/github: tag formats, paths tagging for memory_for_paths) rather than adding new syntax or edge cases, so it earns the baseline but no more.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource: "Write a durable memory into the caller's org." It then immediately disambiguates scope by mapping kinds to pillars and naming the tools that own the rejected kinds (memory_procedure_set / memory_skill_set), so an agent can distinguish it from the dozens of sibling memory_* tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-not guidance is given for procedure/skill with named alternatives, and namespace recall behavior ('recall with the same slug excludes other namespaces') tells the agent how a write affects later retrieval. It does not, however, route against the other write-shaped siblings (memory_session_append, memory_state_set, context_commit), so the alternative coverage is partial.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All TeamShared tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.