Maindex Expert Memory Service

This connector has been deprecated

Replaced by Maindex Expert Memory Service.

Duplicate entry

memory_keep

Create a new memory. Mutates. Not idempotent — calling twice creates two distinct memories. Returns the created memory with id (UUID) and shortId (e.g. mem-1a). When inline links are provided (parent_memory_id, related_memory_ids, or links), the response includes link_summary confirming how many links were created; the memory.links[] field stays empty for performance — use memory_recall to inspect full link details. Tip: include conversation identifiers in conversations to group related memories. CONTENT POLICY: NEVER store passwords, API keys, secrets, credit card numbers, SSNs, government IDs, medical/health records (PHI/HIPAA), biometric data, or any legally protected PII. Sanitize content before storing.

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": {
      "headline": "<headline>"
    },
    "name": "memory_keep"
  }
}

Input Schema

Name	Required	Description	Default
`body`	No	Supporting detail. Omit if the headline is self-contained.
`kind`	No	Memory type: note, fact, idea, summary, artifact, task_context, constraint, question, decision	note
`tags`	No	Tags for categorization. Use facet:name format for structured tags (e.g. domain:cosmology, project:brox).
`team`	No	Team slug filter. Omit for mixed personal+team results. Use "personal" for personal-only.
`links`	No	Typed links to create from this memory
`signer`	No	Agent identity -- who wrote this. Required fields: agent_id, run_id.
`source`	No	Source metadata: origin platform, URI, author, capture time
`headline`	Yes	Title or core assertion of the memory (required)
`metadata`	No	Arbitrary key-value metadata stored as JSON. Opaque to search and ranking.
`stale_at`	No	ISO 8601 datetime when this memory becomes stale
`collection`	No	Target team collection slug. May be bare or prefixed (team:slug). Requires team when writing to a team collection.
`confidence`	No	Confidence as an integer percentage from 0 to 100 (e.g. 85 means 85% confident)
`collections`	No	Collection slugs or IDs to add this memory to
`canon_status`	No	Canonicality: draft, proposed, accepted, deprecated, alternative, meta	draft
`conversations`	No	Conversation contexts this memory belongs to. If you are acting within a named conversation, chat session, or task context, pass its identifier here to enable cross-memory grouping.
`parent_memory_id`	No	Parent memory ID -- creates a belongs_to link
`source_memory_ids`	No	IDs of memories this was derived from (provenance tracking)
`human_collaborator`	No	Human collaborator context (name, email, timezone, etc.)
`related_memory_ids`	No	Related memory IDs -- creates related_to links
`verification_status`	No	Verification status: unverified, verified, disputed, superseded	unverified

Output Schema

Name	Required	Description	Default
`memory`	No	A memory object
`link_summary`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A3.9/5.0

Behavior4/5

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

The description goes well beyond the annotations: annotations only declare idempotentHint=false, while the text explains the consequence ("calling twice creates two distinct memories"), documents the ID/shortId return shape, and discloses the non-obvious link_summary-versus-empty-links[] behavior with a performance rationale. The content policy is also real operational guidance. It loses a point only because it says nothing about failure modes, size/rate limits despite a 1MB body cap, or what happens on auth/permission failure.

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 mutation and non-idempotency facts, then return behavior, then the content policy as a clearly delimited block. Most sentences carry distinct information. It runs long and the tip about conversations partially duplicates the schema's own parameter description, which is the only real waste.

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 20-parameter, deeply nested creation tool with an output schema, this covers the things an agent would otherwise get wrong: that retries duplicate data, what the response contains, why links[] is empty, and what may never be stored. The presence of an output schema relieves it of further return-value explanation, so nothing material is missing.

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?

With schema coverage at 100%, the baseline is 3, and this description earns more: it clarifies the combined effect of parent_memory_id, related_memory_ids, and links (a link_summary rather than populated links[]), and explains why to populate conversations. Content-policy instructions also constrain what may go into headline/body/tags. It does not touch the many provenance and canon fields, but the schema already documents them well.

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?

Opens with a specific verb and resource ("Create a new memory") and immediately characterizes the operation as a mutation. It distinguishes itself from memory_recall by naming it as the follow-up tool for full link details, but gives no signal about how it differs from memory_bulk_keep, memory_update, or memory_supersede, which are the closest siblings in scope.

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

Usage Guidelines3/5

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

Usage is implied by the verb and by the routing hint "use memory_recall to inspect full link details," which is genuinely useful. However, there is no explicit when-to-use versus when-not guidance against the other write-path siblings (bulk_keep, update, supersede), and no stated prerequisites or preconditions for creating versus updating an existing memory.

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

All Maindex Expert Memory Service tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?