Skip to main content
Glama
Sign In
ragflow-kb-mcp

ragflow-kb-mcp

by feci
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

ragflow_create_commit

Destructive

Write, rename, or delete files in a workspace folder and record the change history with a commit message. Target the folder by workspace ID or dataset ID.

Instructions

Commit changes to a workspace folder: writes file content, renames, or deletes files, and records history.

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": {
      "message": "<message>",
      "files": "<files>"
    },
    "name": "ragflow_create_commit"
  }
}

Input Schema

NameRequiredDescriptionDefault
filesYesChanges, each {"file_id", "operation", ...}: operation add or modify needs "file_name" and "content" (text that becomes the file's content), delete needs nothing more, rename needs "old_name" and "new_name". The file_id must be an existing file in the workspace.
messageYesCommit message
dataset_idNoDataset ID; resolves to the dataset's folder. Use instead of workspace_id.
workspace_idNoWorkspace = a folder in the file manager; pass its folder ID. Use dataset_id instead to address the folder that holds a dataset's files.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already mark this as destructive and non-read-only, and the description confirms that it writes, renames, and deletes files and records history. It does not add much beyond annotations, such as atomicity, permission requirements, or irreversibility details, so a baseline 3 is appropriate.

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 definition is a single front-loaded sentence that states the core action and operation scope without repetition or filler. Every clause contributes directly to understanding the tool.

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?

Given the rich annotations, full schema coverage, and output schema, the description is largely complete for an agent to call the tool correctly. It covers the main operation types and history recording, though it could note prerequisites or commit-result handling, which the output schema likely covers.

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 an output schema exists, so the schema already carries full parameter documentation. The description adds no parameter-specific meaning beyond the schema, making the baseline 3 correct.

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 description gives a specific verb and resource: committing changes to a workspace folder, with the operations listed as writes, renames, removes, and history recording. It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools such as ragflow_get_uncommitted_changes or ragflow_diff_commits.

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 'Commit changes to a workspace folder' and the operation list, which suggests when to use it. However, there is no explicit guidance on when not to use it, prerequisites, or which sibling to prefer for inspecting changes before committing.

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