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

ragflow-kb-mcp

by feci
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

ragflow_get_commit_file_content

Read-only

Retrieve a file's content exactly as it existed at a specific commit, using commit and file IDs. Ideal for reviewing past versions or verifying historical changes.

Instructions

Read a file's content as it was at one commit.

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": {
      "commit_id": "<commit_id>",
      "file_id": "<file_id>"
    },
    "name": "ragflow_get_commit_file_content"
  }
}

Input Schema

NameRequiredDescriptionDefault
file_idYesFile or folder ID in the RAGFlow file manager
commit_idYesCommit ID
max_charsNoReturn at most this many characters of text
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

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the genuinely useful behavioral fact that the read is against a historical snapshot rather than live state. It omits material behavior the agent would care about — that output is silently capped at max_chars (default 20000), and how binary/non-text files are handled — so it stops short of full disclosure.

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?

A single front-loaded sentence with no filler or repetition of the title. It is efficient, though for a five-parameter tool with a truncating character budget, one more clause on truncation would have earned its place rather than being padding.

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, annotations cover safety, and all five parameters are documented in the schema, so the essentials are present. The remaining gap is behavioral: silent truncation via max_chars and handling of non-text files are the two things an agent can get wrong here, and neither is mentioned.

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%, so file_id, commit_id, max_chars, dataset_id and workspace_id are all documented in the schema, including the dataset_id vs workspace_id resolution rule. The description contributes nothing beyond that, which is the expected baseline when the schema does the heavy lifting.

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?

States a specific verb and resource ('Read a file's content') plus a qualifying scope ('as it was at one commit'), which cleanly separates it from the current-content siblings like ragflow_download_file and from the commit-metadata siblings like ragflow_get_commit and ragflow_list_commit_files. It doesn't name a sibling explicitly, which keeps it just under a 5.

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?

The historical qualifier 'as it was at one commit' implies when this tool applies versus reading the current file, but the description never states that contrast explicitly, gives no prerequisites (commit must exist, file must be in that commit), and names no alternative. Usage is inferable rather than guided.

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