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-서버
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=falseAPI_ENDPOINT구성에 필요하므로 이 URL을 저장하세요.
Related MCP server: Chalee MCP RAG
특징
도구
query_docs- 문서 Q&A 시스템 쿼리쿼리 문자열을 입력으로 받습니다.
Langflow 백엔드에서 응답을 반환합니다.
개발
종속성 설치:
지엑스피1
서버를 빌드하세요:
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.-