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

ragflow_ingest_documents

Destructive

Start, rerun, cancel, or clear document ingestion and parse pipeline datasets to control RAGFlow knowledge base parsing workflows.

Instructions

Start, rerun, cancel or clear ingestion of documents; also parses datasets that use an ingestion pipeline.

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": {
      "document_ids": "<document_ids>",
      "action": "<action>"
    },
    "name": "ragflow_ingest_documents"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionYesstart: parse documents not parsed yet; rerun: delete existing chunks and parse again; cancel: stop a running parse; clear: delete the parse results without parsing again
document_idsYesIDs of the documents
apply_dataset_configNoCopy the dataset's parser settings to the documents first

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

C2.5/5.0
Behavior2/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known; the description adds nothing beyond that. It does not say what 'clear' destroys, whether operations are async/long-running, or what happens to documents already parsed. The genuinely useful destruction semantics live only in the schema's enum description, not in the tool description.

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

Conciseness3/5

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

It is a single compact sentence with the action list front-loaded, which is good. However, the second clause about datasets and ingestion pipelines is ambiguous enough to cost more attention than it repays.

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

Completeness2/5

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

For a destructive, multi-action mutation tool, the description is too thin: no note on overlap with sibling parse/stop tools, no async or batch expectations, and no clarification of the dataset-pipeline clause. It does benefit from an output schema and 100% parameter coverage, which keeps it from being inadequate.

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 coverage is 100% and the action enum is fully self-documenting, so the schema carries the load. The description contributes no additional meaning about document_ids batch behavior or apply_dataset_config side effects. Baseline 3 applies when the schema already explains every parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (documents) and enumerates the four actions, so the general purpose is legible. But it never distinguishes this tool from its near-identical siblings ragflow_parse_documents and ragflow_stop_parsing, which cover overlapping ground. The trailing clause about parsing 'datasets that use an ingestion pipeline' is vague and muddies rather than sharpens the scope.

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

Usage Guidelines2/5

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

There is no statement of when to choose this tool over ragflow_parse_documents or ragflow_stop_parsing, both of which appear in the sibling list and do adjacent things. An agent must guess whether 'start' here is a synonym for parse_documents or a different path. No prerequisites or exclusions are given.

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