Skip to main content
Glama
esurovtsev

KnowFlow MCP

by esurovtsev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

KnowFlow MCP

License: MIT

A versatile, unified knowledge retrieval tool operating according to the Model Context Protocol (MCP). KnowFlow enhances Large Language Models by providing structured external knowledge on demand.

๐Ÿš€ Overview

KnowFlow simulates a simplified version of Retrieval-Augmented Generation (RAG), enabling LLMs to dynamically fetch context or domain-specific information from external knowledge bases, resulting in precise, context-aware responses.

KnowFlow Architecture

Core Features

  • Responds to knowledge retrieval requests from MCP-compatible LLMs

  • Performs searches across knowledge sources based on queries received from LLMs

  • Provides structured responses with clear source metadata

  • Establishes a foundation for integration with multiple knowledge sources

Related MCP server: MinerU Document Explorer

๐Ÿ“‹ Requirements

  • Node.js (version 16.x or higher)

  • TypeScript (version 4.x or higher)

  • npm or yarn

๐Ÿ› ๏ธ Installation

# Clone the repository
git clone https://github.com/esurovtsev/know-flow-mcp.git
cd know-flow-mcp

# Install dependencies
npm install
# or
yarn install

๐Ÿ”ง Configuration

Create a .env file in the root directory with the following configuration:

KNOWLEDGE_DIR=./knowledge

Where KNOWLEDGE_DIR is the path to the directory containing your knowledge base files (.txt and .md files).

๐Ÿš€ Usage

# Build the project
npm run build
# or
yarn build

# Start the server
npm start
# or
yarn start

๐Ÿ”— MCP Configuration

To use KnowFlow with any MCP-compatible LLMs (such as Claude, GPT-4, etc.), you can use the provided mcp-config.json file:

{
  "mcpServers": {
    "knowflow": {
      "command": "node",
      "args": ["dist/index.js"]
    }
  }
}

This configuration file tells MCP-compatible LLMs how to start and connect to the KnowFlow MCP server. You would typically place this file in your project directory and reference it when setting up the LLM to use MCP servers.

Note: Once KnowFlow is stable and published to npm, the command will change to npx know-flow-mcp instead of node dist/index.js.

๐Ÿงช Testing with MCP Inspector

The MCP Inspector is a tool that allows you to test your MCP server without needing to integrate with an LLM.

# Run the Inspector with your MCP server
npx @modelcontextprotocol/inspector node dist/index.js

This will start the MCP Inspector web interface (typically at http://127.0.0.1:6274) where you can:

  1. View all available tools exposed by the server

  2. Test the search_knowledge tool by sending requests with different parameters

  3. View the responses and debug the communication

If you encounter port conflicts, you can specify custom ports:

npx @modelcontextprotocol/inspector node dist/index.js --port 8080 --proxy-port 8081

Where:

  • --port specifies the web interface port (default: 6274)

  • --proxy-port specifies the proxy server port (default: 6277)

Example Response Format

{
  "content": "We agreed to consolidate all backend modules under a single monorepo using Nx.",
  "metadata": {
    "reference": "architecture-notes.md",
    "source": "docs",
    "lastModified": "2024-03-14",
    "score": 0.95
  }
}

๐Ÿงช Testing

# Run tests
npm test
# or
yarn test

๐Ÿ“ API Documentation

Detailed API documentation will be available once the project reaches a more mature stage.

๐Ÿ—‚๏ธ Project Structure

know-flow-mcp/
โ”œโ”€โ”€ src/                # Source code
โ”‚   โ”œโ”€โ”€ index.ts        # Entry point
โ”‚   โ”œโ”€โ”€ server.ts       # MCP server definition and tool registration
โ”‚   โ”œโ”€โ”€ core/           # Core functionality
โ”‚   โ”œโ”€โ”€ plugins/        # Plugin system for knowledge sources
โ”‚   โ””โ”€โ”€ services/       # Services including KnowledgeService
โ”œโ”€โ”€ dist/               # Compiled JavaScript files
โ”œโ”€โ”€ .gitignore          # Git ignore file
โ”œโ”€โ”€ LICENSE             # MIT License
โ”œโ”€โ”€ package.json        # Project metadata and dependencies
โ”œโ”€โ”€ README.md           # Project documentation
โ””โ”€โ”€ tsconfig.json       # TypeScript configuration

๐Ÿ”Œ Plugin System

KnowFlow uses a plugin-based architecture to integrate with different knowledge sources:

  • Plugins are discovered synchronously at startup

  • Each plugin represents a different knowledge source (docs, jira, confluence, etc.)

  • The KnowledgeService coordinates searches across all available plugins

  • New knowledge sources can be added by implementing the plugin interface

๐Ÿ”ฎ Future Roadmap

The foundational design explicitly anticipates integration with additional knowledge sources such as:

  • Notion pages

  • Confluence documentation

  • Google Docs documents

  • Linear and Jira issues or tickets

  • Other popular knowledge repositories utilized by developers and organizations

๐Ÿค Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

๐Ÿ“„ License

This project is licensed under the MIT License - see the LICENSE file for details.

Available Tools

1 tool
search_knowledgeA

Searches for information in the knowledge base. Use this tool when you need to retrieve specific information or context.

Available knowledge sources:
    - docs: For architecture documents, technical specifications, and notes

IMPORTANT USAGE INSTRUCTIONS:
  1. This tool returns content snippets directly from the knowledge base
  2. DO NOT attempt to access or load the source files mentioned in metadata
  3. Use ONLY the content field from each result to answer queries
  4. ALWAYS cite the EXACT source filenames (including .md extension) when presenting information to users (e.g., 'According to architecture-notes.md...')
  5. Source filenames help users understand where information comes from and allow them to verify it if needed
  6. The lastModified field indicates when the information was updated - newer information may be more relevant
  7. The score field (0-1) indicates how relevant the result is to the query - higher values are more relevant
  8. All necessary information is contained in the content snippets

Response format:
{
  instructions: "How to use these results",
  results: [
    {
      content: "The actual text snippet to use (FOCUS ON THIS)",
      metadata: {
        reference: "Filename for reference only - DO NOT ATTEMPT TO LOAD",
        source: "docs",
        lastModified: "Date of last modification",
        score: "Relevance score between 0-1"
      }
    }
  ]
}
ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of results to return
queryYesThe search query to find relevant information
sourceNoThe preferred knowledge source to search (e.g., jira, confluence, docs, slack). If specified, results from this source will be prioritized.

TDQS

A3.8/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It reveals that the tool returns content snippets, includes metadata fields (score, lastModified), and warns against accessing source files. It implies a read-only operation, though it does not explicitly declare read-only. Overall, it provides good behavioral context.

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?

The description is verbose, containing a full response format example and multiple usage bullet points. While structured, it could be more concise. Every sentence contributes, but the length may reduce quick comprehension.

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?

With no output schema, the description compensates by providing a detailed response format with explanations of each field (content, metadata, reference, score, etc.). It also covers usage instructions and result interpretation. For a 3-parameter tool, this is fairly complete.

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%, so baseline is 3. The description adds some value by listing the 'docs' source and instructing on using score/lastModified, but it does not significantly enhance the schema descriptions for 'query' and 'limit'. The source parameter is somewhat enhanced with an example list, but not enough to raise the score.

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 clearly states 'Searches for information in the knowledge base' and lists an available source ('docs'). This provides a specific verb and resource, but it does not distinguish from potential sibling tools (none provided), and the purpose is somewhat broad.

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

Usage Guidelines4/5

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

The description explicitly says 'Use this tool when you need to retrieve specific information or context.' It also provides detailed usage instructions (e.g., 'DO NOT attempt to access or load the source files', 'Use ONLY the content field') that guide the agent on proper use. There are no sibling tools to compare against, but the guidance is clear.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.1.0
    • First observedsearch_knowledge
Deploy Server
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

TDQS

A3.7/5.0

Scored across 1 tool

Disambiguation5/5

There is only one tool, so no ambiguity exists between tools. The tool's purpose is clearly defined as searching a knowledge base.

Naming Consistency5/5

With a single tool, naming is inherently consistent. The name 'search_knowledge' follows a clear verb_noun pattern.

Tool Count2/5

A single search tool is insufficient for a knowledge base server. Typically, such servers would include create, update, and delete tools to manage knowledge entries.

Completeness2/5

The server lacks any tools beyond search. There are no create, update, or delete operations, which are essential for managing a knowledge base.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • MinerU Document Explorer by opendatalab

    MinerU Document Explorerofficial

    opendatalab
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI agents to search, deep-read, and build knowledge bases from Markdown, PDF, DOCX, and PPTX documents via MCP tools for retrieval, document navigation, and ingestion.
    16 npm
    633
    MIT

  • RAG MCP Server

    torkian
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables Claude Desktop to search custom knowledge bases using retrieval-augmented generation via a simple MCP tool.
    MIT