open-memex

Overview Schema Source Related Servers Discussions Admin

memory_submit

Submit outbox drafts into repository memory for review: runs graph lint, applies deterministic curation, commits locally, and prints push/PR commands without publishing.

Instructions

Move outbox drafts into the repo memory dir for review. Before copying, reports graph lint (never blocking) and auto-applies only deterministic curation: exact-duplicate merges, empty-body archives, and first-line title normalization. Near-duplicates are reported, never merged. Every applied action appears in the output with its undo command; pass noCurate=true to skip the auto-apply tier while keeping the lint report. Then copies the drafts in as proposed (or keeps a local approval), commits locally on the current branch, and moves the outbox originals out. Never creates a branch on its own — pass branch= only with the user's explicit approval for the full chain. Prints the push and PR commands — those need the user's explicit approval and are never run automatically. (MCP server and the open-memex submit CLI; the opencode native plugin does not expose this tool.) Unknown ids or a failed local commit abort the submit with the reason; nothing is published automatically.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ids": "<ids>"
    },
    "name": "memory_submit"
  }
}

Input Schema

Name	Required	Description
`ids`	Yes	Outbox draft ids to submit.
`base`	No	PR base branch override. Default: the branch the submit ran on.
`branch`	No	Create this branch and submit onto it. If omitted, submit stays on the current branch — branches are never auto-created. Only pass this when the user explicitly approved the full chain (branch + push + PR).
`noCurate`	No	Skip the deterministic pre-submit auto-apply tier; the graph lint report still runs. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.10.0Nov 14, 2026

addedInput schema / properties / noCurate

Added value: +{
+  "description": "Skip the deterministic pre-submit auto-apply tier; the graph lint report still runs. Default false.",
+  "type": "boolean"
+}

First observedOct 5, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false) by disclosing the curation tiers (only deterministic: exact-duplicate merges, empty-body archives, title normalization), that near-duplicates are reported but never merged, that lint is non-blocking, that every applied action comes with an undo command, and that unknown ids or a failed commit abort the submit. It also discloses the side effects of moving outbox originals and committing locally, plus the explicit approval gates for branch creation and push/PR.

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?

The core action is front-loaded and the dense sequence of behavioral guarantees follows in roughly execution order. It is long and repeats the branch-approval rule already stated in the branch parameter description, so a small amount of the text is redundant rather than load-bearing.

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 multi-step mutating tool with no output schema, the description covers the full lifecycle: lint, curation tier, draft copy, local commit, outbox removal, and the printed (not executed) push/PR commands, plus failure modes. An agent has everything needed to call it correctly and to know what will not happen automatically.

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% and each of the four parameters is already documented in the schema. The description reinforces the semantics of noCurate and the approval constraint on branch=, but adds no syntax, format, or default detail beyond what the schema already provides, so the baseline 3 applies.

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

Purpose4/5

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

The first sentence states a specific verb+resource+destination: move outbox drafts into the repo memory dir for review. That is clear enough to distinguish it from siblings like memory_propose or memory_promote, but the description never explicitly names an alternative, leaving the agent to infer the boundary from names alone.

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?

Strong conditional guidance: use noCurate=true to skip auto-apply while keeping lint, pass branch= only with explicit user approval for the full chain, and push/PR commands are printed but never run. What is missing is when-to-use guidance relative to sibling tools (e.g., propose vs submit), so the routing decision is only implicit.

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

Deploy Server