F
licenseNot graded
qualityD
maintenanceEnables semantic search and question-answering over FAQ documents using RAG (Retrieval-Augmented Generation) with OpenAI embeddings and in-memory vector similarity.
-
Langflow Document Q&A Server
by GongRzhe
Langflow-DOC-QA-SERVER
Langflow を利用したドキュメント Q&A 用のモデル コンテキスト プロトコル サーバー
これは、ドキュメントQ&Aシステムを実装したTypeScriptベースのMCPサーバーです。Langflowバックエンドを介してドキュメントをクエリするためのシンプルなインターフェースを提供することで、MCPのコアコンセプトを実証しています。
前提条件
1. LangflowドキュメントQ&Aフローを作成する
Langflowを開き、「ドキュメントQ&A」テンプレートから新しいフローを作成します。
必要なコンポーネント (ChatInput、ファイルアップロード、LLM など) を使用してフローを構成します。
フローを保存する
2. Flow APIエンドポイントを取得する
Langflowの右上隅にある「API」ボタンをクリックします。
cURL コマンドから API エンドポイント URL をコピーします。例:
http://127.0.0.1:7860/api/v1/run/<flow-id>?stream=falseこのURLは
API_ENDPOINT設定に必要となるので保存してください。
Related MCP server: Chalee MCP RAG
特徴
ツール
query_docs- ドキュメントQ&Aシステムを照会するクエリ文字列を入力として受け取ります
Langflowバックエンドからの応答を返します
発達
依存関係をインストールします:
npm installサーバーを構築します。
npm run build自動リビルドを使用した開発の場合:
npm run watchインストール
Claude Desktop で使用するには、サーバー設定を追加します。
MacOS の場合: ~/Library/Application Support/Claude/claude_desktop_config.json Windows の場合: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"langflow-doc-qa-server": {
"command": "node",
"args": [
"/path/to/doc-qa-server/build/index.js"
],
"env": {
"API_ENDPOINT": "http://127.0.0.1:7860/api/v1/run/480ec7b3-29d2-4caa-b03b-e74118f35fac"
}
}
}
}Smithery経由でインストール
Smithery経由で Claude Desktop 用の Document Q&A Server を自動的にインストールするには:
npx -y @smithery/cli install @GongRzhe/Langflow-DOC-QA-SERVER --client claude環境変数
サーバーは、構成用に次の環境変数をサポートしています。
API_ENDPOINT: Langflow APIサービスのエンドポイントURL。指定されていない場合は、デフォルトでhttp://127.0.0.1:7860/api/v1/run/480ec7b3-29d2-4caa-b03b-e74118f35facになります。
デバッグ
MCPサーバーはstdio経由で通信するため、デバッグが困難になる場合があります。パッケージスクリプトとして提供されているMCP Inspectorの使用をお勧めします。
npm run inspectorインスペクターは、ブラウザでデバッグ ツールにアクセスするための URL を提供します。
📜 ライセンス
このプロジェクトは MIT ライセンスに基づいてライセンスされています。
Available Tools
1 toolquery_docsC
Query the document Q&A system with a prompt
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The query prompt to search for in the documents |
TDQS
C2.6/5.0
Behavior2/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 of behavioral disclosure. It mentions querying a 'document Q&A system', which implies a read-only operation, but doesn't specify behavioral traits like response format, error handling, rate limits, or authentication needs. The description is too minimal to provide adequate transparency for safe and effective use.
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?
The description is a single, clear sentence: 'Query the document Q&A system with a prompt'. It's front-loaded and efficiently conveys the core action without unnecessary words. However, it could be slightly more informative without losing conciseness, such as by specifying the system's purpose or output type.
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?
Given the tool's complexity (a query tool with no annotations and no output schema), the description is incomplete. It lacks details on what the tool returns, how results are formatted, any limitations, or error conditions. Without annotations or an output schema, the description should provide more context to help the agent understand the tool's behavior and outcomes, but it falls short.
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?
The input schema has 100% description coverage, with the 'query' parameter documented as 'The query prompt to search for in the documents'. The description adds no additional meaning beyond this, as it doesn't elaborate on query syntax, examples, or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 states the tool 'Query the document Q&A system with a prompt', which provides a basic verb ('Query') and resource ('document Q&A system'), making the purpose somewhat clear. However, it's vague about what 'document Q&A system' entails and doesn't specify the scope or type of documents, leaving room for ambiguity. Without sibling tools, it doesn't need differentiation, but the purpose could be more specific.
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?
The description offers no guidance on when to use this tool, such as what types of queries it supports, prerequisites, or limitations. It simply states the action without context, leaving the agent to infer usage from the tool name and parameters alone. This lack of explicit or implied guidelines reduces its helpfulness in selecting the tool appropriately.
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 tool update
- First observed
query_docs
TDQS
C2.9/5.0
Scored across 1 tool
Disambiguation5/5
With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool 'query_docs' has a clear and distinct purpose for querying documents, so agents cannot misselect among multiple options.
Naming Consistency5/5
The naming is trivially consistent as there is only one tool. It follows a verb_noun pattern ('query_docs'), which is clear and predictable, and there are no other tools to cause inconsistency or mixed conventions.
Tool Count2/5
The tool count is too low for a server with the apparent scope of a 'Document Q&A Server'. A single query tool feels thin and incomplete, as it lacks supporting operations like document upload, management, or retrieval, which are typical for such a domain.
Completeness2/5
The tool surface is significantly incomplete for a document Q&A system. While 'query_docs' allows querying, there are obvious gaps such as no tools for adding, updating, deleting, or listing documents, which are essential for a functional document management and query workflow.
Maintenance
ActivityInactive
ResponsivenessNo issues
Related MCP Connectors
Ingest, manage, and retrieve documents for RAG-powered AI applications
Query any docs site via MCP. Submit a URL, ask questions, get cited answers.
Query Klaaro datasets, documents, and extracted records from any agent.
Retrieve information from the Medusa documentation to assist you with your Medusa development.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables RAG (Retrieval-Augmented Generation) capabilities with document processing, vector storage, and intelligent Q\&A using OpenAI embeddings and semantic search.-
- AlicenseNot gradedqualityBmaintenanceEnables document-based Q&A with multi-modal RAG, hybrid retrieval, knowledge graph reasoning, and multi-agent orchestration via MCP tools.4MIT
- FlicenseNot gradedqualityCmaintenanceEnables querying internal documents via a FastAPI REST API and MCP server, using retrieval-augmented generation and an agentic loop that can invoke tools like document search and calculations.-