Skip to main content
Glama
ragflow-kb-mcp
by feci

ragflow_add_memory_message

Saves a user/agent exchange to specified memories and triggers background extraction, preserving conversation context for later retrieval.

Instructions

Save one user/agent exchange to memories; extraction runs in the background.

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": {
      "memory_ids": "<memory_ids>",
      "agent_id": "<agent_id>",
      "session_id": "<session_id>",
      "user_id": "<user_id>",
      "user_input": "<user_input>",
      "agent_response": "<agent_response>"
    },
    "name": "ragflow_add_memory_message"
  }
}

Input Schema

NameRequiredDescriptionDefault
user_idYesID of the user in the conversation (required with API keys)
agent_idYesID of the agent the dialogue came from
memory_idsYesIDs of the memories to use
session_idYesID of the conversation session
user_inputYesWhat the user said
agent_responseYesWhat the agent answered

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare this is a non-destructive write (readOnlyHint=false, destructiveHint=false, openWorldHint=false). The description adds the one genuinely non-obvious behavioral trait: 'extraction runs in the background', so the agent knows results are asynchronous and won't appear immediately. It does not say what extraction produces, whether duplicate exchanges are tolerated, or what happens if memory_ids is empty, so it is not exhaustive.

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?

A single front-loaded sentence that states the action first and the async caveat second, with no filler. Everything present earns its place given the schema carries parameter detail.

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

Completeness3/5

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, for a 6-required-parameter write tool with many memory-related siblings, the definition omits where this fits in the memory lifecycle and what the background extraction eventually affects — enough context to call it, not enough to call it confidently.

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% — all six parameters (user_id, agent_id, memory_ids, session_id, user_input, agent_response) are documented inline. The description adds nothing about parameter meaning, but per the baseline rule full schema coverage justifies a 3.

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?

Clear specific verb + resource: 'Save one user/agent exchange to memories' tells the agent exactly what is created and at what granularity (a single exchange, not a batch). It does not name or contrast with a sibling (e.g. ragflow_create_memory, ragflow_set_memory_message_status), so it stops short of the top score.

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 only implied: documenting an exchange implies calling it after an agent response within a session. There is no explicit when/when-not guidance and no mention of alternatives such as ragflow_create_memory (create the memory container) or ragflow_search_memory_messages, leaving the agent to infer the workflow.

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