Skip to main content
Glama
Sign In
MemAI

MemAI

by Filipe-Soares-de-Almeida
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

move_to_project

Destructive

Move memories from the active project into another project, purging them from the source after a verified transfer and backup; preview with dry_run first.

Instructions

Carry memories from the active project into another one, and remove them here.

Each memory travels whole -- body, cross-listings, usage counts, edit history, the relations and diagram graph inside the slice -- into target, is checked there, and only then purged from the active project, after a backup of it is written.

Input Schema

NameRequiredDescriptionDefault
uidsNocomma-separated memories to move; give uids, domain or both.
createNomakes a `target` that does not exist yet.
domainNoa path to move, its subdomains and archived rows included.
targetYesthe project to move into; list_projects() names the projects there are.
dry_runNothe default, and moves nothing: it reports what would move, `conflicts` (uids `target` already holds, which stay here), `unknown` (uids asked for that this project does not hold) and `outside` -- the relations, diagram links and jumps, `superseded_by` marks and [[uid]] references that cross the edge of the slice, all of which the move drops. Each comes as `count`, the whole number, and up to 20 `items`. Read that report with the user, then widen the slice or accept the loss BEFORE calling again with dry_run=False: the purge is irreversible short of the backup.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changedv0.16.1
    • addedInput schema / properties / create / description
      Added value: +"makes a `target` that does not exist yet."
    • removedInput schema / properties / create / title
      Removed value: -"Create"
    • addedInput schema / properties / domain / description
      Added value: +"a path to move, its subdomains and archived rows included."
    • removedInput schema / properties / domain / title
      Removed value: -"Domain"
    • addedInput schema / properties / dry_run / description
      Added value: +"the default, and moves nothing: it reports what would move, `conflicts` (uids `target` already holds, which stay here), `unknown` (uids asked for that this project does not hold) and `outside` -- the relations, diagram links and jumps, `superseded_by` marks and [[uid]] references that cross the edge of the slice, all of which the move drops. Each comes as `count`, the whole number, and up to 20 `items`. Read that report with the user, then widen the slice or accept the loss BEFORE calling again with dry_run=False: the purge is irreversible short of the backup."
    • removedInput schema / properties / dry_run / title
      Removed value: -"Dry Run"
    • addedInput schema / properties / target / description
      Added value: +"the project to move into; list_projects() names the projects there are."
    • removedInput schema / properties / target / title
      Removed value: -"Target"
    • addedInput schema / properties / uids / description
      Added value: +"comma-separated memories to move; give uids, domain or both."
    • removedInput schema / properties / uids / title
      Removed value: -"Uids"
    • removedInput schema / title
      Removed value: -"move_to_projectArguments"
  2. Addedv0.1.1

TDQS

A4.3/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and readOnlyHint=false, but the description goes well beyond: it explains the copy-then-verify-then-purge sequencing, what gets dropped on crossing the slice boundary (relations, diagram links, jumps, superseded_by marks, [[uid]] references), that conflicts/unknown/outside items are reported, and that the purge is irreversible short of the backup. This is rich behavioral context annotations alone cannot convey.

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?

Two well-structured sentences that front-load the core action and then disclose the staging behavior. Slightly dense but every clause carries weight; no filler.

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

Completeness4/5

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

For a destructive 5-param move tool with no output schema, the description covers the lifecycle (move, verify, purge, backup) and the drop semantics, and it points to list_projects for target discovery via the schema. It stops short of describing the backup location/format or what 'checked there' concretely validates, leaving a small gap.

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 coverage is 100%, so each parameter already carries its own description. The description adds framing (the dry_run workflow and the meaning of the report) but doesn't enrich individual field semantics beyond what the schema provides. Baseline 3 is appropriate.

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?

Specific verb ('carry', 'remove') plus resource ('memories') plus explicit source/target scoping ('from the active project into another one'). Clearly distinguished from siblings like forget, purge_memory, and list_projects, which don't move memories across projects.

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?

Establishes a clear workflow: dry_run defaults to true, read the report, then call again with dry_run=False. This implicitly tells the agent when to proceed vs. pause. However, it does not name alternative siblings (e.g., why not forget + note) or state exclusions, so it falls short of 5.

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

Deploy Server

Other Tools