contextforge-mcp

memory_ingest

Save important context to persistent memory for future use: capture project decisions, user preferences, debugging insights, deadlines, and any 'remember this' requests so nothing is lost.

Instructions

Save important context to persistent memory — be proactive. Call this WHENEVER you learn information that would be valuable in a future conversation: project decisions ('we chose Postgres because X'), architectural choices, user preferences, debugging insights, recurring patterns, deadlines, stakeholder context, or any 'remember this' / 'save this' / 'note that' style request from the user. Heuristic: if you would be sad to lose this fact when the conversation ends, ingest it. Better to over-save than to under-save — the memory_query semantic search will surface what's relevant later. Always pass meaningful title and tags so the item is discoverable. Set deduplicate:false to save even if identical content already exists. ROUTE BY TOPIC: pass space:"<name>" matching the memory's topic so it lands in the right space instead of the catch-all default. If you don't yet know the project's spaces, call cf_tools with query "list spaces" once and reuse the result. Saving without space: piles everything into one default space — avoid it in multi-space projects.

Input Schema

TableJSON Schema

Name	Required	Description
`tags`	No	Optional tags for categorization
`title`	No	Optional title for the content
`content`	Yes	The content to store in memory
`category`	No	Optional category
`space_id`	No	Space UUID (uses default if not specified)
`source_uri`	No	Optional source URI (file path, URL, etc.)
`deduplicate`	No	Skip saving if identical content already exists (default: true). Set to false to force a copy even when a duplicate is detected.
`source_type`	No	Type of source (default: manual)
`related_paths`	No	Files/dirs this memory is about (e.g. ["src/api.ts"]). Enables staleness detection when that code changes.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.0.6Jul 25, 2026

addedInput schema / properties / deduplicate

Added value: +{
+  "description": "Skip saving if identical content already exists (default: true). Set to false to force a copy even when a duplicate is detected.",
+  "type": "boolean"
+}

addedInput schema / properties / related_paths

Added value: +{
+  "description": "Files/dirs this memory is about (e.g. [\"src/api.ts\"]). Enables staleness detection when that code changes.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

Addedv1.0.4May 22, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already signal read/write behavior (readOnlyHint=false, destructiveHint=false), and the description adds meaningful behavioral context: deduplication semantics (default true, with guidance to set false), and the consequence of omitting space (piles into default space). It also implies long-term persistence and retrieval via semantic search. No contradiction detected; only minor missing detail like side effects on existing entries, but not required given annotations.

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

Conciseness5/5

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

The description is long but tightly structured with bold headings, front-loading the core purpose and examples, then routing guidance. Every sentence earns its place; no fluff or repetition. The length is justified by the tool's complexity and the need to convey proactivity and space routing.

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?

Given the complexity (9 params, multiple behaviors) and absence of an output schema, the description covers when to use, what to save, parameter priorities, space routing, deduplication, and how to discover spaces. No critical missing information. The only minor gap is return behavior, but without an output schema that's not required. Complete for effective use.

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

Parameters4/5

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

Schema covers 100% of parameters, so baseline is 3. The description adds value by emphasizing meaningful title and tags for discoverability, explaining space_id's role via 'pass space:'<name>'' and default fallback, and clarifying deduplicate behavior. Not all parameters are elaborated (source_uri, related_paths), but those are self-explanatory and don't require extra context. This exceeds the baseline.

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?

The description states a specific verb ('save'), a resource ('persistent memory'), and a clear scope: information valuable for future conversations, with concrete examples like project decisions and user preferences. It also conveys proactivity and distinguishes itself from memory_query by noting that query will later surface what was saved. This fully differentiates the tool's purpose.

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

Usage Guidelines5/5

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

Provides explicit when-to-use guidance ('Call this WHENEVER...'), a decision heuristic ('if you would be sad to lose this fact'), and preference for over-saving. It also gives routing instructions with spaces, including how to discover spaces via cf_tools, and warns against default-space usage in multi-space projects. This is exceptionally actionable.

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

Deploy Server

memory_ingest

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools