de en es ja ko ru zh

QA MCP Server

Name: QA MCP Server
Author: sanumenon

by sanumenon

Overview Schema Related Servers Score Discussions

Python

Remote

QA MCP Server

확장 가능한 AI 기반 QA 플랫폼을 목표로 설계된 Model Context Protocol(MCP) 서버입니다.

현재 상태

Phase 1 — 기반 및 QA 인텔리전스

완료됨

단계	기능	상태
1	프로젝트 기반	완료됨
2	MCP 서버 + 상태 확인	완료됨
3	LLM 공급자 추상화	완료됨
4	요구사항 분석기	완료됨
5	테스트 케이스 생성기	완료됨
6	테스트 케이스 검토자	완료됨
7	종단 간 QA 작업 흐름	완료됨

Phase 2 — 프로젝트 컨텍스트, 영속성, 버전 관리 및 이식성

단계	기능	상태
1	QA 프로젝트 컨텍스트	완료됨
2	SQLite 영속성	완료됨
3	QA 스위트 버전 관리	완료됨
4	가져오기 / 내보내기	완료됨

1. 비전

장기적인 목표는 MCP 호환 AI 클라이언트에 QA 기능을 제공하는 재사용 가능한 QA MCP 플랫폼을 구축하는 것입니다.

MCP Client / AI Assistant
          |
          v
      QA MCP Server
          |
   +------+------+------+
   |             |      |
   v             v      v
QA Intelligence Connectors Automation
   |             |      |
Analyze        Jira    UI
Generate       GitHub  API
Review         Slack   Mobile
                       Performance
          |
          v
       QA Agent
          |
          v
 Persistent QA Context
          |
          v
 Project / Requirement / Suite Versions
          |
          v
 Import / Export

2. Phase 1 아키텍처

Requirement
     |
     v
Requirement Analyzer
     |
     v
RequirementAnalysis
     |
     v
Test Case Generator
     |
     v
TestCaseResponse
     |
     v
Test Case Reviewer
     |
     v
TestCaseReview
     |
     v
QASuiteResult

핵심 MCP 기능:

analyze_requirement
generate_test_cases
review_test_cases
generate_qa_suite

3. LLM 아키텍처

LLMProvider
     |
     +---- MockLLM
     |
     +---- BedrockLLM

LLM 접근은 공급자 독립적이므로, QA 도구를 로컬에서 테스트한 후 AWS Bedrock 또는 다른 공급자에 연결할 수 있습니다.

AI 출력은 다운스트림 처리 전에 Pydantic 모델을 통해 검증됩니다.

4. Phase 2 1단계 — QA 프로젝트 컨텍스트

** 상태: 완료 **

QA 프로젝트에는 다음이 포함됩니다:

QAProject
 |
 +-- project_id
 +-- name
 +-- description
 +-- application
 +-- environment
 +-- metadata

핵심 서비스:

ProjectContext
 |
 +-- create_project()
 +-- get_project()

MCP 도구:

create_qa_project
get_qa_project

5. Phase 2 2단계 — SQLite 영속성

** 상태: 완료 **

프로젝트는 다음에 영속화됩니다:

data/qa_mcp.db

SQLite 테이블:

qa_projects

아키텍처:

ProjectContext
       |
       v
ProjectRepository
       |
       v
SQLiteProjectRepository
       |
       v
SQLite

핵심 컨텍스트는 SQLite에 직접 의존하지 않습니다.

서로 다른 Python 프로세스에서 영속성이 검증되었습니다.

6. Phase 2 3단계 — QA 스위트 버전 관리

** 상태: 완료 **

QA 요구 사항과 생성된 스위트는 독립적으로 버전이 관리되고 영속화됩니다.

Related MCP server: QTM4J MCP Server

요구 사항 버전

QA Project
   |
   +-- Requirement v1
   +-- Requirement v2
   +-- Requirement v3

각 요구 사항 버전에는 다음이 포함됩니다:

version_id
project_id
version
requirement
application
environment
created_at

버전은 프로젝트별로 독립적으로 유지됩니다.

스위트 버전

각 스위트는 해당 스위트를 생성한 요구 사항 버전을 기록합니다:

Requirement v1
      |
      v
Suite v1

Requirement v2
      |
      v
Suite v2

각 스위트 버전에는 다음이 포함됩니다:

suite_id
project_id
requirement_version_id
version
test_cases
review
created_at

아키텍처

core/
└── versioning/
    └── service.py
        |
        v
infrastructure/
└── versioning/
    ├── repositories.py
    └── sqlite_version_repository.py
        |
        v
      SQLite

두 versioning 폴더는 의도적인 것입니다:

core/versioning 은 비즈니스 로직을 담습니다.
infrastructure/versioning 은 리포지토리 인터페이스 및 SQLite 구현체를 담습니다.

핵심 서비스

QARequirementVersioningService
QASuiteVersioningService

리포지토리 인터페이스

RequirementVersionRepository
SuiteVersionRepository

SQLite 구현체

SQLiteRequirementVersionRepository
SQLiteSuiteVersionRepository

MCP 도구

요구 사항:

create_requirement_version
get_requirement_version
list_requirement_versions

스위트:

create_suite_version
get_suite_version
list_suite_versions

7. Phase 2 4단계 — 가져오기 / 내보내기

** 상태: 완료 **

QA MCP 서버는 이제 이식 가능한 프로젝트 아티팩트를 지원하며, 여기에는 다음이 포함됩니다:

QA Project
    |
    +-- Requirement Versions
    |
    +-- Suite Versions

export

export 흐름은 다음과 같습니다:

SQLite
   |
   +-- Project
   +-- Requirement Versions
   +-- Suite Versions
           |
           v
QAImportExportService
           |
           v
QAProjectExport
           |
           v
JSON

export는 호출자가 조립한 객체가 아닌 영속화된 데이터를 기반으로 합니다.

MCP 도구:

export_qa_project

입력:

project_id

출력:

{
    "project_id": "...",
    "export_version": "1.0",
    "payload": "..."
}

import

import 흐름은 다음과 같습니다:

JSON
  |
  v
Parse
  |
  v
QAProjectExport validation
  |
  v
Relationship validation
  |
  v
Duplicate project check
  |
  v
SQLite persistence

MCP 도구:

import_qa_project

import는 다음을 검증합니다:

export JSON
export 구조
프로젝트 identity
요구사항 → 프로젝트 관계
스위트 → 프로젝트 관계
스위트 → 요구사항-버전 관계
중복 프로젝트 보호

기존 프로젝트는 조용히 덮어쓰지 않습니다.

라운드 트립 검증

완전한 라운드 트립이 끝난 후에도 검증이 확인되었습니다:

SQLite DB A
    |
    v
EXPORT
    |
    v
JSON
    |
    v
IMPORT
    |
    v
SQLite DB B
    |
    v
Compare

검증된 아티팩트:

Project           ✅
Requirements      ✅
Suites            ✅
Relationships     ✅

테스트 격리

MCP import/export 테스트는 격리된 임시 SQLite 데이터베이스를 사용합니다.

이를 통해 테스트 실행이 다음을 오염시키는 것을 방지하고:

data/qa_mcp.db

이전 테스트 상태에 의존하지 않고 반복적으로 테스트 실행할 수 있습니다.

P2-S4 패키지 / 검증 기준

Import/Export focused tests: 7 passed
MCP Import/Export tests:     2 passed
Full regression:            49 passed
Application-code warnings:   0
Known external warning:      1

나머지 경고는 lifespan 필드의 해결되지 않은 전환 참조와 관련된 알려진 외부 pydantic_settings 경고입니다.

8. 프로젝트 구조

현재 중요한 소스 구조:

qa-mcp/
|
+-- src/
|   +-- qa_mcp/
|       |
|       +-- core/
|       |   +-- config.py
|       |   +-- llm.py
|       |   +-- project/
|       |   |   +-- context.py
|       |   |
|       |   +-- versioning/
|       |   |   +-- service.py
|       |   |
|       |   +-- import_export/
|       |       +-- service.py
|       |
|       +-- infrastructure/
|       |   +-- project_repository.py
|       |   +-- sqlite_project_repository.py
|       |   |
|       |   +-- versioning/
|       |       +-- repositories.py
|       |       +-- sqlite_version_repository.py
|       |
|       +-- models/
|       |   +-- schemas.py
|       |
|       +-- tools/
|       |   +-- requirement/
|       |   +-- testcase/
|       |   +-- workflow/
|       |
|       +-- server.py
|
+-- tests/
+-- config/
+-- data/
|   +-- qa_mcp.db
|
+-- README.md

9. 로컬 설정

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

테스트 실행:

pytest -q

현재 검증된 기준:

49 passed

MCP 서버 실행:

python -m qa_mcp.server

서버 가져오기 blib 확인:

G-35

10. 개발 가이드/라이

모든 구현 단계는 다음 작업 흐름을 따릅니다:

IMPLEMENT
    |
    v
FOCUSED TESTS
    |
    v
FULL REGRESSION
    |
    v
RUNTIME / MCP VERIFICATION
    |
    v
FIX / REFINE
    |
    v
MARK STEP COMPLETE
    |
    v
UPDATE README
    |
    v
DOWNLOAD NEW README CHECKPOINT
    |
    v
NEXT STEP

규칙:

한 번에 하나의 단계를 구현합니다.
모든 기능을 테스트합니다.
기존 테스트는 계속 통과 상태를 유지해야 합니다.
** 단계는 완료로 간주되지 않습니다. 5. 로컬에서 검증되기 전에 완료되지 않습니다.
검증된 각 이정표에서 README를 업데이트합니다.
핵심 비즈니스 로직은 MCP 전송에 대해 독립적이어야 합니다.
영속성 및 외부 통합은 인터페이스 스키로 고립됩니다.
LLM 프로파이더는 교재체 가능한 상태로 유지됩니다.
AI 출력은 검증되어야 합니다.
테스트는 영속 저장소에 대해 반복 가능해야 합니다.
테스트를 통과시키기 위해 영속 데이터베이스의 프로 파일을 삭제하지 마십시오.
영속성 관련 테스트에는 격리된 데이터베이스를 사용하십시오.
어시스턴트 대화를 README에 수동으로 복사하지 마십니다.
README 문서는 검증될 수 있는 개발 체크포인트입니다.
MCP/런타임 경로가 검증되지 않은 기능은 완전히 구현된 것으로 간주되지 않습니다.

11. 아키텍처 원칙

핵심 비즈니스 로직은 core에 속합니다.
영속성은 infrastructure에 속합니다.
MCP 전송은 server.py와 MCP 외부 인터페이스 도구에 속합니다.
도메인/데이터 모델은 models에 속합니다.
핵심 서비스는 SQLite 구현에 직접 의존해서는 안 됩니다.
외부 통합은 인터페이스 뒤에 격리되어야 합니다.
LLM 공급자는 교체체 가능해야 합니다.
AI 생성 출력은 다운스트림 사용 전에 반드시 검증해야 합니다.
영속 데이터는 테스트 init data와 혼동되어서는 안 됩니다.
테스트는 반복 가능해야 합니다.
import 작업은 영속화 전에 관계를 검증해야 합니다.
import 는 기존 프로젝트를 조용히 덮어쓰지 않아야 합니다.
완료된 주요 단계는 회귀 검증가 필요합니다.
README 업데이트는 마일스톤 완료의 일부입니다.

12. Phase 2 실행 로드맵

단계	기능	상태
1	QA 프로젝트 컨텍스트	완료되었습니다
2	SQLite 영속성	완료되었습니다
3	QA 스위트 버전 관리	완료되었습니다
4	import / export	완료되었습니다
5	Jira 커넥터	다음
6	Jira → QA 작업 흐름	계획됨
7	자동화 케이스 생성기	계획됨
8	QA Agent	계획됨
9	GitHub / CI 통합	계획됨
10	인터넷 배포	계획됨

13. 예상 최종 아키텍처

                    MCP CLIENT / AI ASSISTANT
                              |
                              v
                       +-------------+
                       |   QA MCP    |
                       |   Server    |
                       +------+------+
                              |
              +---------------+----------------+
              |               |                |
              v               v                v
        QA Intelligence   Connectors      Automation
              |               |                |
        +-----+-----+     +---+---+       +----+----+
        |     |     |     |   |   |       |    |    |
     Analyze Gen  Review Jira GitHub    UI   API  Perf
                                            Mobile
              |
              v
          QA Agent
              |
              v
       Persistent Context
              |
              v
     Project / Requirement
        / Suite Versions
              |
              v
       Import / Export

14. 현재 기준 Baseline

Phase 1
  Steps 1–7  COMPLETED

Phase 2
  Step 1 — QA Project Context       COMPLETED
  Step 2 — SQLite Persistence       COMPLETED
  Step 3 — QA Suite Versioning      COMPLETED
  Step 4 — Import / Export          COMPLETED

현재 검증:

49 tests passed
SQLite persistence verified
Requirement versioning verified
Suite versioning verified
Import/export contract verified
Import validation verified
Round-trip persistence verified
MCP import/export verified
MCP server imports successfully
Test isolation verified

알려진 경고:

pydantic_settings
IncompleteFieldDefinitionWarning
Field 'lifespan'

이것은 외부 의존성 경고이며, 현재 기능이나 테스트를 차단하지 않습니다.

15. 다음 개발 단계

Phase 2 → Step 5
       |
       v
Jira Connector

이 README 체크포인트가 기록된 후에만 다음 구현 단계가 시작되어야 합니다.

16. 마일스톤 이력

Phase 1
  |
  +-- Foundation
  +-- LLM abstraction
  +-- Requirement analysis
  +-- Test generation
  +-- Test review
  +-- QA suite workflow
  +-- MCP integration
  |
  v
Phase 1 COMPLETE

Phase 2
  |
  +-- QA Project Context
  +-- SQLite Persistence
  +-- Requirement/Suite Versioning
  +-- Import / Export
  |
  v
Phase 2 Step 4 COMPLETE

이 README는 Phase 2 → 단계 4 — Import / Export 가 성공적으로 검증된 후의 프로젝트 상태를 나타냅니다.

Wait, I see some errors in my draft: "각" etc. Need check.

Need ensure "COMPLETED" translations consistent. Also "P2-S4 verification baseline" we wrote "P2-S4 패키지 /tmp 기준" because auto mistranslation? Let's correct.

Need ensure no translation errors. Let's systematically rewrite.

We should be meticulous.

Let's craft new final with translations.

Potential tricky: "QA MCP server" translate as "QA MCP 서버". "An extensible Model Context Protocol (MCP) server designed to become a unified AI-powered QA platform." -> "확장 가능한 Model Context Protocol(MCP) 서버로, 통합 AI 기반 QA 플랫폼이 되는 것을 목표로 설계되었습니다."

"unified AI-powered QA platform" -> "통합 AI 기반 QA 플랫폼".

Phase: I'll translate "Phase 1" as "1단계" maybe. But "Phase 1 Architecture" -> "1단계 아키텍처". "Phase 2 Step 1" -> "2단계 1단계". "Roadmap" table step names: "QA Project Context" etc. Should "QA" stay? It's an acronym, keep. "Project" maybe "프로젝트". We can translate. But "QA Project Context" as technical capability could be "QA 프로젝트 컨텍스트". "SQLite Persistence" can be "SQLite 영속성" or keep "SQLite Persistence" perhaps. But since we're translating, use Korean.

Need determine "Status" values. "COMPLETED" -> "완료됨". "NEXT" -> maybe "다음 단계". "Planned" -> "계획됨". Use that.

Potential issue: "### Phase 1 — Foundation & QA Intelligence" contains "QA Intelligence" proper. We can translate "기반 & QA 지능" but maybe "기반 및 QA 인텔리전스". Use "기반 및 QA 인텔리전스".

"test cases" -> "테스트 케이스", "Requirement Analyzer" -> "요구사항 분석기". Good.

"Requirement → project relationship" -> "요구사항 → 프로젝트 관계".

"Not silently overwritten": "기존 프로젝트는 조용히 덮어쓰지 않습니다."

"Verified artifacts": "검증된 아티팩트".

"Round-trip": "라운드트립(round-trip)" maybe use "왕복". But "round trip" has nuance. Could say "라운드트립 검증". Use "라운드트립".

"test isolation" -> "테스트 격리". "polluting" -> "오염시키는".

"Run the MCP server:" -> "MCP 서버 실행:". "Run server imports" -> "서버 임포트 확인:" but "imports" "모듈 가져오기가 성공하는지 확인" maybe too much. It says "Verify server imports:" so "서버 임포트 확인:".

"Development Guidelines" -> "개발 가이드라인" or "개발 지침". Use "개발 가이드라인".

"Architectural Principles" -> "아키텍처 원칙".

"Roadmap" -> "로드맵".

"Milestone History" -> "마일스톤 이력".

Need maintain all list items and bullet lists.

Now careful with "Owned by" placeholders. We need not translate GXP. OK.

Let's produce a refined final.

Double-check grammar and naturalness.

One more nuance: "MCP-facing tools" in Principle 3. "MCP-facing" is technical, translate as "MCP 대면 도구" or "MCP 인터페이스 도구". Could say "MCP 지향 도구". Use "MCP 지향 도구".

"Persistence must not be confused with test fixtures" -> "영속 데이터는 테스트 픽스처와 혼동해서는 안 됩니다." Use "픽스처" as technical term. Good.

"failed forward reference" -> "전방 참조". In Korean, often "순방향 참조" or "전방 참조" when speaking of type annotations. Use "순방향 참조". Actually Python error "forward reference" (name defined later) -> "앞으로 참조" but not common. Use "순방향 참조".

Need not translate Pydantic, it's verbatim.

Let's consider the table header in section 1: "| Step | Capability | Status |" We should keep "Step" maybe "단계". The instruction says preserve structure exactly, not necessarily header words. So can translate.

Let's craft final.

Potential problem: In input there are two horizontal rules (***) after Phase 2 table and before #1 Vision. We preserve.

Let's transduce.

We'll include "Phase 1" in section #2? It says "# 2. Phase 1 Architecture". I might translate to "# 2. 1단계 아키텍처" but keep "Phase"? Hmm, if "Phase 1" is a product milestone, maybe not translate. But "상태" sections "Phase 2 Step 2" etc. Usually Korean READMEs leave "Phase 2" intact sometimes. Since user said "Translate prose only," translating "Phase" to "단계" is appropriate. But heading "Phase 1 Architecture" is a label; translating is fine. However to preserve "the exact structure" not words. I'll translate to "1단계 아키텍처".

Likewise "Phase 2 Step 1" -> "2단계 1단계" (a bit redundant but fine). Or "2단계 — 1단계". We'll use "2단계 step 1?" Actually "Phase 2 Step 1" would be "2단계 스텝 1" or "2단계 1단계". Use "2단계 1단계".

Let's final.

Need ensure "GXP" placeholders in section restore after corrections: e.g. GXP1, GXP2, GXP3 ... up to GXP42. We need enumerate correctly per input.

Input placeholders:

GXP1 GXP2 GXP3 GXP4 GXP5 GXP6 GXP7 GXP8 GXP9 GXP10 GXP11 GXP12 GXP13 GXP14 GXP15 GXP16 GXP17 GXP18 GXP19 GXP20 GXP21 GXP22 GXP23 GXP24 GXP25 GXP26 GXP27 GXP28 GXP29 GXP30 GXP31 GXP32 GXP33 GXP34 GXP35 GXP36 GXP37 GXP38 GXP39 GXP40 GXP41 GXP42

In input section 6 MCP tools has GXP16 and GXP17? Let's inspect original: "## MCP tools\n\nRequirement:\n\nGXP16\n\nSuite:\n\nGXP17" Wait there are two GXP? Let's check original: Actually original section 6:

MCP tools

Requirement:

create_requirement_version
get_requirement_version
list_requirement_versions

Suite:

create_suite_version
get_suite_version
list_suite_versions

Because earlier "Core services" GXP14, "Repository interfaces" GXP15, "SQLite implementations" GXP16, then "MCP tools": requirement GXP17, suite GXP18. I earlier mistaken.

Let's use proper numbering from original.

Input:

GXP1 after vision. Section 2: GXP2, GXP3. Section3: GXP4. Section4: GXP5, GXP6, GXP7. Section5: GXP8, GXP9, GXP10. Section6: GXP11, GXP12, GXP13, GXP14, GXP15, GXP16, GXP17, GXP18. Section7: GXP19. Export: GXP20, GXP21, GXP22, GXP23. Import: GXP24, GXP25. Round trip: GXP26, GXP27. Test isolation: GXP28. Baseline: GXP29. Section8: GXP30. Section9: GXP31, GXP32, GXP33, GXP34, GXP35. Section10: GXP36. Section13: GXP37. Section14: GXP38, GXP39, GXP40. Section15: GXP41. Section16: GXP42.

Yes. Use correct.

So in section6: Core services GXP14, Repository GXP15, SQLite impl GXP16, MCP tools: Requirement GXP17, Suite GXP18.

Let's ensure.

Also "Current important source structure" includes GXP30.

Now final polished.

One detail: In section 14 "Current verification: GXP39" after GXP38, yes.

Let's produce final without any code fences, just text.# QA MCP Server

확장 가능한 Model Context Protocol(MCP) 서버로, 통합 AI 기반 QA 플랫폼을 목표로 설계되었습니다.

현재 상태

1단계 — 기반 및 QA 인텔리전스

완료됨

단계	기능	상태
1	프로젝트 기반	완료됨
2	MCP 서버 + 상태 확인	완료됨
3	LLM 공급자 추상화	완료됨
4	요구사항 분석기	완료됨
5	테스트 케이스 생성기	완료됨
6	테스트 케이스 검토자	완료됨
7	엔드투엔드 QA 워크플로	완료됨

2단계 — 프로젝트 컨텍스트, 영속성, 버전 관리 및 이식성

단계	기능	상태
1	QA 프로젝트 컨텍스트	완료됨
2	SQLite 영속성	완료됨
3	QA 스위트 버전 관리	완료됨
4	가져오기 / 내보내기	완료됨

1. 비전

장기적인 목표는 MCP 호환 AI 클라이언트에 QA 기능을 노출하는 재사용 가능한 QA MCP 플랫폼을 구축하는 것입니다.

MCP Client / AI Assistant
          |
          v
      QA MCP Server
          |
   +------+------+------+
   |             |      |
   v             v      v
QA Intelligence Connectors Automation
   |             |      |
Analyze        Jira    UI
Generate       GitHub  API
Review         Slack   Mobile
                       Performance
          |
          v
       QA Agent
          |
          v
 Persistent QA Context
          |
          v
 Project / Requirement / Suite Versions
          |
          v
 Import / Export

2. 1단계 아키텍처

Requirement
     |
     v
Requirement Analyzer
     |
     v
RequirementAnalysis
     |
     v
Test Case Generator
     |
     v
TestCaseResponse
     |
     v
Test Case Reviewer
     |
     v
TestCaseReview
     |
     v
QASuiteResult

핵심 MCP 기능:

analyze_requirement
generate_test_cases
review_test_cases
generate_qa_suite

3. LLM 아키텍처

LLMProvider
     |
     +---- MockLLM
     |
     +---- BedrockLLM

LLM 접근은 공급자와 무관하므로 QA 도구를 로컬에서 테스트하고 이후에 AWS Bedrock 또는 다른 공급자에 연결할 수 있습니다.

AI 출력은 다운스트림 처리 전에 Pydantic 모델을 사용하여 검증됩니다.

4. 2단계 1단계 — QA 프로젝트 컨텍스트

상태: 완료됨

QA 프로젝트에는 다음이 포함됩니다:

QAProject
 |
 +-- project_id
 +-- name
 +-- description
 +-- application
 +-- environment
 +-- metadata

핵심 서비스:

ProjectContext
 |
 +-- create_project()
 +-- get_project()

MCP 도구:

create_qa_project
get_qa_project

5. 2단계 2단계 — SQLite 영속성

상태: 완료됨

프로젝트는 다음에 영속화됩니다:

data/qa_mcp.db

SQLite 테이블:

qa_projects

아키텍처:

ProjectContext
       |
       v
ProjectRepository
       |
       v
SQLiteProjectRepository
       |
       v
SQLite

핵심 컨텍스트는 SQLite에 직접 의존하지 않습니다.

영속성은 별도의 Python 프로세스에서 검증되었습니다.

6. 2단계 3단계 — QA 스위트 버전 관리

상태: 완료됨

QA 요구사항과 생성된 스위트는 독립적으로 버전 관리되고 영속화됩니다.

요구사항 버전

QA Project
   |
   +-- Requirement v1
   +-- Requirement v2
   +-- Requirement v3

각 요구사항 버전에는 다음이 포함됩니다:

version_id
project_id
version
requirement
application
environment
created_at

버전은 프로젝트별로 독립적으로 유지됩니다.

스위트 버전

각 스위트는 해당 스위트를 생성한 요구사항 버전을 기록합니다:

Requirement v1
      |
      v
Suite v1

Requirement v2
      |
      v
Suite v2

각 스위트 버전에는 다음이 포함됩니다:

suite_id
project_id
requirement_version_id
version
test_cases
review
created_at

아키텍처

core/
└── versioning/
    └── service.py
        |
        v
infrastructure/
└── versioning/
    ├── repositories.py
    └── sqlite_version_repository.py
        |
        v
      SQLite

두 개의 versioning 폴더는 의도적으로 구성되었습니다:

core/versioning 은 비즈니스 로직을 포함합니다.
infrastructure/versioning 은 리포지토리 인터페이스와 SQLite 구현을 포함합니다.

핵심 서비스

QARequirementVersioningService
QASuiteVersioningService

리포지토리 인터페이스

RequirementVersionRepository
SuiteVersionRepository

SQLite 구현

SQLiteRequirementVersionRepository
SQLiteSuiteVersionRepository

MCP 도구

요구사항:

create_requirement_version
get_requirement_version
list_requirement_versions

스위트:

create_suite_version
get_suite_version
list_suite_versions

7. 2단계 4단계 — 가져오기 / 내보내기

상태: 완료됨

QA MCP 서버는 이제 다음을 포함하는 이식 가능한 프로젝트 아티팩트를 지원합니다:

QA Project
    |
    +-- Requirement Versions
    |
    +-- Suite Versions

내보내기

내보내기 흐름은 다음과 같습니다:

SQLite
   |
   +-- Project
   +-- Requirement Versions
   +-- Suite Versions
           |
           v
QAImportExportService
           |
           v
QAProjectExport
           |
           v
JSON

내보내기는 호출자가 조립한 객체가 아닌 영속화된 데이터를 기반으로 합니다.

MCP 도구:

export_qa_project

입력:

project_id

출력:

{
    "project_id": "...",
    "export_version": "1.0",
    "payload": "..."
}

가져오기

가져오기 흐름은 다음과 같습니다:

JSON
  |
  v
Parse
  |
  v
QAProjectExport validation
  |
  v
Relationship validation
  |
  v
Duplicate project check
  |
  v
SQLite persistence

MCP 도구:

import_qa_project

가져오기는 다음을 검증합니다:

내보내기 JSON
내보내기 구조
프로젝트 ID
요구사항 → 프로젝트 관계
스위트 → 프로젝트 관계
스위트 → 요구사항-버전 관계
중복 프로젝트 보호

기존 프로젝트는 조용히 덮어쓰지 않습니다.

왕복 검증

완전한 왕복 처리가 검증되었습니다:

SQLite DB A
    |
    v
EXPORT
    |
    v
JSON
    |
    v
IMPORT
    |
    v
SQLite DB B
    |
    v
Compare

검증된 아티팩트:

Project           ✅
Requirements      ✅
Suites            ✅
Relationships     ✅

테스트 격리

MCP 가져오기/내보내기 테스트는 격리된 임시 SQLite 데이터베이스를 사용합니다.

이를 통해 테스트 실행이 다음을 오염시키지 않습니다:

data/qa_mcp.db

또한 이전 테스트 상태에 의존하지 않고 반복적으로 테스트를 실행할 수 있습니다.

P2-S4 검증 기준

Import/Export focused tests: 7 passed
MCP Import/Export tests:     2 passed
Full regression:            49 passed
Application-code warnings:   0
Known external warning:      1

남은 경고는 lifespan 필드의 해결되지 않은 전방 참조와 관련된 알려진 외부 pydantic_settings 경고입니다.

8. 프로젝트 구조

현재 중요한 소스 구조:

qa-mcp/
|
+-- src/
|   +-- qa_mcp/
|       |
|       +-- core/
|       |   +-- config.py
|       |   +-- llm.py
|       |   +-- project/
|       |   |   +-- context.py
|       |   |
|       |   +-- versioning/
|       |   |   +-- service.py
|       |   |
|       |   +-- import_export/
|       |       +-- service.py
|       |
|       +-- infrastructure/
|       |   +-- project_repository.py
|       |   +-- sqlite_project_repository.py
|       |   |
|       |   +-- versioning/
|       |       +-- repositories.py
|       |       +-- sqlite_version_repository.py
|       |
|       +-- models/
|       |   +-- schemas.py
|       |
|       +-- tools/
|       |   +-- requirement/
|       |   +-- testcase/
|       |   +-- workflow/
|       |
|       +-- server.py
|
+-- tests/
+-- config/
+-- data/
|   +-- qa_mcp.db
|
+-- README.md

9. 로컬 설정

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

테스트 실행:

pytest -q

현재 검증된 기준:

49 passed

MCP 서버 실행:

python -m qa_mcp.server

서버 임포트 확인:

python -c "from qa_mcp.server import mcp; print('MCP server imports OK')"

10. 개발 지침

모든 구현 단계에서 다음 워크플로를 따릅니다:

IMPLEMENT
    |
    v
FOCUSED TESTS
    |
    v
FULL REGRESSION
    |
    v
RUNTIME / MCP VERIFICATION
    |
    v
FIX / REFINE
    |
    v
MARK STEP COMPLETE
    |
    v
UPDATE README
    |
    v
DOWNLOAD NEW README CHECKPOINT
    |
    v
NEXT STEP

규칙:

한 번에 한 단계씩 구현합니다.
모든 기능을 테스트합니다.
기존 테스트는 계속 통과해야 합니다.
로컬 검증 전에는 어떤 단계도 완료로 간주하지 않습니다.
검증된 마일스톤마다 README를 업데이트합니다.
핵심 비즈니스 로직은 MCP 전송과 독립적이어야 합니다.
지속성과 외부 통합은 인터페이스 뒤에 유지합니다.
LLM 공급자는 교체 가능한 상태로 유지합니다.
AI 출력은 반드시 검증되어야 합니다.
테스트는 영구 저장소에 대해 반복 가능해야 합니다.
테스트를 통과시키기 위해 영구 저장소(DB)를 삭제하지 마십시오.
지속성 중심 테스트에는 격리된 데이터베이스를 사용합니다.
어시스턴트 대화를 수동으로 README에 복사하지 마십시오.
README는 권위 있는 개발 체크포인트입니다.
MCP/런타임 경로가 검증되기 전까지 주요 기능은 완료로 간주하지 않습니다.

11. 아키텍처 원칙

핵심 비즈니스 로직은 core에 속합니다.
지속성은 infrastructure에 속합니다.
MCP 전송은 server.py와 MCP 지향 도구에 속합니다.
도메인/데이터 모델은 models에 속합니다.
핵심 서비스는 SQLite 구현에 직접 의존해서는 안 됩니다.
외부 통합은 인터페이스 뒤에 격리되어야 합니다.
LLM 공급자는 교체 가능한 상태로 유지됩니다.
AI 생성 출력은 후속 작업 전에 반드시 검증되어야 합니다.
영구 데이터는 테스트 픽스처와 혼동되어서는 안 됩니다.
테스트는 반복 가능해야 합니다.
가져오기 작업은 영속화 전에 관계를 검증해야 합니다.
가져오기는 기존 프로젝트를 조용히 덮어쓰면 안 됩니다.
완료된 마일스톤에는 회귀 검증이 필요합니다.
README 업데이트는 마일스톤 완료의 일부입니다.

12. 2단계 로드맵

단계	기능	상태
1	QA 프로젝트 컨텍스트	완료됨
2	SQLite 지속성	완료됨
3	QA 스위트 버전 관리	완료됨
4	가져오기 / 내보내기	완료됨
5	Jira 연결	다음 단계
6	Jira → QA 워크플로	계획됨
7	자동화 케이스 생성기	계획됨
8	QA 에이전트	계획됨
9	GitHub / CI 통합	계획됨
10	인터넷 배포	계획됨

13. 계획된 최종 아키텍처

                    MCP CLIENT / AI ASSISTANT
                              |
                              v
                       +-------------+
                       |   QA MCP    |
                       |   Server    |
                       +------+------+
                              |
              +---------------+----------------+
              |               |                |
              v               v                v
        QA Intelligence   Connectors      Automation
              |               |                |
        +-----+-----+     +---+---+       +----+----+
        |     |     |     |   |   |       |    |    |
     Analyze Gen  Review Jira GitHub    UI   API  Perf
                                            Mobile
              |
              v
          QA Agent
              |
              v
       Persistent Context
              |
              v
     Project / Requirement
        / Suite Versions
              |
              v
       Import / Export

14. 현재 기준

Phase 1
  Steps 1–7  COMPLETED

Phase 2
  Step 1 — QA Project Context       COMPLETED
  Step 2 — SQLite Persistence       COMPLETED
  Step 3 — QA Suite Versioning      COMPLETED
  Step 4 — Import / Export          COMPLETED

현재 검증:

49 tests passed
SQLite persistence verified
Requirement versioning verified
Suite versioning verified
Import/export contract verified
Import validation verified
Round-trip persistence verified
MCP import/export verified
MCP server imports successfully
Test isolation verified

알려진 경고:

pydantic_settings
IncompleteFieldDefinitionWarning
Field 'lifespan'

이는 외부 의존성 경고이며 현재 기능이나 테스트를 차단하지 않습니다.

15. 다음 개발 단계

Phase 2 → Step 5
       |
       v
Jira Connector

이 README 체크포인트가 확보된 이후에만 다음 구현 단계를 시작해야 합니다.

16. 마일스톤 기록

Phase 1
  |
  +-- Foundation
  +-- LLM abstraction
  +-- Requirement analysis
  +-- Test generation
  +-- Test review
  +-- QA suite workflow
  +-- MCP integration
  |
  v
Phase 1 COMPLETE

Phase 2
  |
  +-- QA Project Context
  +-- SQLite Persistence
  +-- Requirement/Suite Versioning
  +-- Import / Export
  |
  v
Phase 2 Step 4 COMPLETE

이 README는 2단계 → 4단계 — 가져오기 / 내보내기 의 성공적인 검증 이후의 프로젝트 상태를 나타냅니다.

Let's review minor errors: "G부분" - I wrote "G부분" instead of GXP30? Wait in #8 I wrote "G부분"? Need fix. Let's prepare final clean.

I notice a mistake: in section 8 "G부분" accidentally. Need replace with "GXP30".

Also in section 1 title "## 현재 상태" fine.

In line "LLM 접근은" "Access" could "접근". Good.

"QA MCP 서버" uses "능력" could be "기능". Fine.

Need ensure "많은" not.

Let's create a final message with all correct text.

Also ensure "string" quote: "2단계 → 4단계 — 가져오기 / 내보내기" keeps the arrow.

"Phase 2 → Step 4" would be "2단계 → 4단계" but "Step 4" is "단계 4" or "4단계". Good.

Need not include English "Step" but okay.

Let's now produce final clean# QA MCP Server

확장 가능한 Model Context Protocol(MCP) 서버로, 통합 AI 기반 QA 플랫폼이 되는 것을 목표로 설계되었습니다.

현재 상태

1단계 — 기반 및 QA 인텔리전스

완료됨

단계	기능	상태
1	프로젝트 기반	완료됨
2	MCP 서버 + 상태 확인	완료됨
3	LLM 공급자 추상화	완료됨
4	요구사항 분석기	완료됨
5	테스트 케이스 생성기	완료됨
6	테스트 케이스 검토자	완료됨
7	종단 간 QA 워크플로	완료됨

2단계 — 프로젝트 컨텍스트, 영속성, 버전 관리 및 이식성

단계	Capability	상태
1	QA 프로젝트 컨텍스트	완료됨
2	SQLite 영속성	완료됨
3	QA 스위트 버전 관리	완료됨
4	가져오기 / 내보내기	완료됨

1. 비전

장기적인 목표는 MCP 호환 AI 클라이언트에 QA 기능을 제공하는 재사용 가능한 QA MCP 플랫폼을 구축하는 것입니다.

MCP Client / AI Assistant
          |
          v
      QA MCP Server
          |
   +------+------+------+
   |             |      |
   v             v      v
QA Intelligence Connectors Automation
   |             |      |
Analyze        Jira    UI
Generate       GitHub  API
Review         Slack   Mobile
                       Performance
          |
          v
       QA Agent
          |
          v
 Persistent QA Context
          |
          v
 Project / Requirement / Suite Versions
          |
          v
 Import / Export

2. 1단계 아키텍처

Requirement
     |
     v
Requirement Analyzer
     |
     v
RequirementAnalysis
     |
     v
Test Case Generator
     |
     v
TestCaseResponse
     |
     v
Test Case Reviewer
     |
     v
TestCaseReview
     |
     v
QASuiteResult

핵심 MCP 기능:

analyze_requirement
generate_test_cases
review_test_cases
generate_qa_suite

3. LLM 아키텍처

LLMProvider
     |
     +---- MockLLM
     |
     +---- BedrockLLM

LLM 접근은 공급자에 독립적이므로 QA 도구를 로컬에서 테스트하고, 이후 AWS Bedrock이나 다른 공급자에 연결할 수 있습니다.

AI 출력은 다운스트림 처리 전에 Pydantic 모델을 사용하여 검증됩니다.

4. 2단계 1단계 — QA 프로젝트 컨텍스트

상태: 완료됨

QA 프로젝트에는 다음이 포함됩니다:

QAProject
 |
 +-- project_id
 +-- name
 +-- description
 +-- application
 +-- environment
 +-- metadata

핵심 서비스:

ProjectContext
 |
 +-- create_project()
 +-- get_project()

MCP 도구:

create_qa_project
get_qa_project

5. 2단계 2단계 — SQLite 영속성

상태: 완료됨

프로젝트는 다음에 영속화됩니다:

data/qa_mcp.db

SQLite 테이블:

qa_projects

아키텍처:

ProjectContext
       |
       v
ProjectRepository
       |
       v
SQLiteProjectRepository
       |
       v
SQLite

핵심 컨텍스트는 SQLite에 직접 의존하지 않습니다.

영속성은 별도의 Python 프로세스에서 검증되었습니다.

6. 2단계 3단계 — QA 스위트 버전 관리

상태: 완료됨

QA 요구사항과 생성된 스위트는 버전이 관리되고 독립적으로 영속화됩니다.

요구사항 버전

QA Project
   |
   +-- Requirement v1
   +-- Requirement v2
   +-- Requirement v3

각 요구사항 버전에는 다음이 포함됩니다:

version_id
project_id
version
requirement
application
environment
created_at

버전은 프로젝트별로 독립적으로 유지됩니다.

스위트 버전

각 스위트는 자신을 생성한 요구사항 버전을 기록합니다:

Requirement v1
      |
      v
Suite v1

Requirement v2
      |
      v
Suite v2

각 스위트 버전에는 다음이 포함됩니다:

suite_id
project_id
requirement_version_id
version
test_cases
review
created_at

리포지토리 구조

core/
└── versioning/
    └── service.py
        |
        v
infrastructure/
└── versioning/
    ├── repositories.py
    └── sqlite_version_repository.py
        |
        v
      SQLite

두 개의 versioning 폴더는 의도적으로 설계되었습니다:

core/versioning에는 비즈니스 로직이 들어 있습니다.
infrastructure/versioning에는 repository 인터페이스와 SQLite 구현이 들어 있습니다.

핵심 서비스

QARequirementVersioningService
QASuiteVersioningService

Repository 인터페이스

RequirementVersionRepository
SuiteVersionRepository

SQLite 구현체

SQLiteRequirementVersionRepository
SQLiteSuiteVersionRepository

MCP 도구

요구사항:

create_requirement_version
get_requirement_version
list_requirement_versions

스위트:

create_suite_version
get_suite_version
list_suite_versions

7. 2단계 4단계 — 가져오기 / 내보내기

상태: 완료됨

QA MCP 서버는 이제 다음을 포함한 휴대 가능한 프로젝트 아티팩트를 지원합니다:

QA Project
    |
    +-- Requirement Versions
    |
    +-- Suite Versions

내보내기

내보내기 흐름은 다음과 같습니다:

create_suite_version
get_suite_version
list_suite_versions

SQLite
   |
   +-- Project
   +-- Requirement Versions
   +-- Suite Versions
           |
           v
QAImportExportService
           |
           v
QAProjectExport
           |
           v
JSON

내보내기는 호출 측에서 조립한 객체가 아니라 영속화된 데이터를 기반으로 합니다.

MCP 도구:

export_qa_project

입력:

project_id

출력:

{
    "project_id": "...",
    "export_version": "1.0",
    "payload": "..."
}

가져오기

가져오기 흐름은 다음과 같습니다:

JSON
  |
  v
Parse
  |
  v
QAProjectExport validation
  |
  v
Relationship validation
  |
  v
Duplicate project check
  |
  v
SQLite persistence

MCP 도구:

import_qa_project

가져오기는 다음 항목을 검증합니다.

JSON 내보내기 유효성
JSON 내보내기 구조
프로젝트 ID
요구사항 → 프로젝트 관계
스위트 → 프로젝트 관계
스위트 → 요구사항 버전 관계
가져오기 중복 보호

기존 프로젝트를 조용히 보고 덮어쓰지 않습니다.

Round-trip 검증

전체 라운드 트립은 성공적으로 검증되었습니다:

SQLite DB A
    |
    v
EXPORT
    |
    v
JSON
    |
    v
IMPORT
    |
    v
SQLite DB B
    |
    v
Compare

검증된 산출물:

Project           ✅
Requirements      ✅
Suites            ✅
Relationships     ✅

테스트 격리

MCP 가져오기/내보내기 테스트는 반드시 격리된 임시 SQLite 데이터베이스를 사용합니다.

이렇게 함으로써 테스트 실행이 다음을 오염시키지 않도록 방지합니다:

data/qa_mcp.db

또한 이전 테스트 상태에 의존하지 않고 테스트를 반복 실행할 수 있습니다.

P2-S4 검증 기준

Import/Export focused tests: 7 passed
MCP Import/Export tests:     2 passed
Full regression:            49 passed
Application-code warnings:   0
Known external warning:      1

남은 경고는 lifespan 필드의 미해결 전방 참조에 대한 알려진 외부 pydantic_settings 경고입니다.

8. 프로젝트 구조

현재 중요한 소스 구조는 다음과 같습니다:

qa-mcp/
|
+-- src/
|   +-- qa_mcp/
|       |
|       +-- core/
|       |   +-- config.py
|       |   +-- llm.py
|       |   +-- project/
|       |   |   +-- context.py
|       |   |
|       |   +-- versioning/
|       |   |   +-- service.py
|       |   |
|       |   +-- import_export/
|       |       +-- service.py
|       |
|       +-- infrastructure/
|       |   +-- project_repository.py
|       |   +-- sqlite_project_repository.py
|       |   |
|       |   +-- versioning/
|       |       +-- repositories.py
|       |       +-- sqlite_version_repository.py
|       |
|       +-- models/
|       |   +-- schemas.py
|       |
|       +-- tools/
|       |   +-- requirement/
|       |   +-- testcase/
|       |   +-- workflow/
|       |
|       +-- server.py
|
+-- tests/
+-- config/
+-- data/
|   +-- qa_mcp.db
|
+-- README.md

9. 로컬 설정

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

테스트 실행:

pytest -q

현재 검증 기준:

49 passed

MCP 서버 실행:

python -m qa_mcp.server

서버 import 검증:

python -c "from qa_mcp.server import mcp; print('MCP server imports OK')"

10. 개발 가이드라인

모든 구현 단계에서 다음 워크플로를 따릅니다:

IMPLEMENT
    |
    v
FOCUSED TESTS
    |
    v
FULL REGRESSION
    |
    v
RUNTIME / MCP VERIFICATION
    |
    v
FIX / REFINE
    |
    v
MARK STEP COMPLETE
    |
    v
UPDATE README
    |
    v
DOWNLOAD NEW README CHECKPOINT
    |
    v
NEXT STEP

규칙:

한 단계씩 구현합니다.
모든 기능을 테스트합니다.
기존 테스트는 계속 통과해야 합니다.
로컬 검증이 완료될 때까지 해당 단계는 완료되지 않습니다.
모든 검증된 마일스톤마다 README를 업데이트합니다.
핵심 비즈니스 로직은 MCP 전송에 독립적이어야 합니다.
영속성과 외부 통합 기능은 인터페이스 뒤에 유지되어야 합니다.
LLM 공급자는 항상 교체할 수 있어야 합니다.
AI 생성 데이터는 항상 검증되어야 합니다.
테스트는 영구 저장소를 대상으로 반복 실행 가능해야 합니다.
테스트 통과를 위해 영구 데이터베터를 삭제해서는 안 됩니다.
테스트 격리에는 별도의 격리 데이터베이스를 사용합니다.
도우미 대화 내용을 README에 직접 복사하지 마십시오.
README는 항상 커밋된 개발 상태를 반영해야 합니다.
모든 주요 기능은 MCP / 런타임 단계에서 검증되기 전까지는 완료로 간주하지 않습니다.

11. 아키텍처 원칙

핵심 비즈니스 로직은 core에 있어야 합니다.
영속화는 infrastructure에 있어야 합니다.
MCP 전송은 server.py 및 MCP와 관련된 도구에 있습니다.
도메인/데이터 모델은 models에 있어야 합니다.
핵심 서비스는 SQLite 구현을 직접 참조해서는 안 됩니다.
외부 통합은 반드시 인터페이스 뒤에 고립되어야 합니다.
LLM 공급자는 항상 교체하기 쉬운 구조여야 합니다.
AI 생성 출력은 사용에 앞서 항상 유효성을 검증해야 합니다.
영구적인 데이터는 테스트 픽스처와 혼동되어서는 안 됩니다.
테스트는 반드시 반복 가능해야 합니다.
가져오기 작업은 영속화 전에 관계성을 검증해야 합니다.
가져오기 과정에서 기존 프로젝트를 조용히 덮어쓰지 않아야 합니다.
완료된 마일스톤은 항사 회귀 테스트를 통해 검증되어야 합니다.
README 업데이트는 마일스톤 완료의 일부입니다.

12. 2단계 로드맵

단계	기능	상태
1	QA 프로젝트 컨텍스트	완료됨
2	SQLite 영속화	완료됨
3	QA 스위트 버전 관리	완료됨
4	가져오기 / 내보내기	완료됨
5	Jira 커넥터	다음 단계
6	Jira → QA 워크플로	계획됨
7	자동화 테스트 생성기	계획됨
8	QA 에이전트	계획됨
9	GitHub / CI 통합	계획됨
10	인터넷 배포	계획됨

13. 예상 최종 아키텍처

                    MCP CLIENT / AI ASSISTANT
                              |
                              v
                       +-------------+
                       |   QA MCP    |
                       |   Server    |
                       +------+------+
                              |
              +---------------+----------------+
              |               |                |
              v               v                v
        QA Intelligence   Connectors      Automation
              |               |                |
        +-----+-----+     +---+---+       +----+----+
        |     |     |     |   |   |       |    |    |
     Analyze Gen  Review Jira GitHub    UI   API  Perf
                                            Mobile
              |
              v
          QA Agent
              |
              v
       Persistent Context
              |
              v
     Project / Requirement
        / Suite Versions
              |
              v
       Import / Export

14. 현재 기준

Phase 1
  Steps 1–7  COMPLETED

Phase 2
  Step 1 — QA Project Context       COMPLETED
  Step 2 — SQLite Persistence       COMPLETED
  Step 3 — QA Suite Versioning      COMPLETED
  Step 4 — Import / Export          COMPLETED

현재 검증:

49 tests passed
SQLite persistence verified
Requirement versioning verified
Suite versioning verified
Import/export contract verified
Import validation verified
Round-trip persistence verified
MCP import/export verified
MCP server imports successfully
Test isolation verified

알려진 경고:

pydantic_settings
IncompleteFieldDefinitionWarning
Field 'lifespan'

이 경고는 외부 종속성 경고이며 현재 기능이나 테스트를 막지는 않습니다.

15. 다음 개발 단계

Phase 2 → Step 5
       |
       v
Jira Connector

구현은 이 README checkpoint가 확정된 후에 다음 단계를 시작해야 합니다.

16. 마일스톤 기록

Phase 1
  |
  +-- Foundation
  +-- LLM abstraction
  +-- Requirement analysis
  +-- Test generation
  +-- Test review
  +-- QA suite workflow
  +-- MCP integration
  |
  v
Phase 1 COMPLETE

Phase 2
  |
  +-- QA Project Context
  +-- SQLite Persistence
  +-- Requirement/Suite Versioning
  +-- Import / Export
  |
  v
Phase 2 Step 4 COMPLETE

이 README는 2단계 → 4단계 — Import / Export 가 성공적으로 검증된 이후의 프로젝트 상태를 나타냅니다.

This server cannot be installed

license - not found

Not graded

quality - not tested

maintenance

How are these scores calculated?

Maintenance

–Maintainers

–Response time

–Release cycle

–Releases (12mo)

Commit activity

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Servers

qasphere-mcp
Testing & QA Tools Developer Tools
Hypersequent
A
license
A
quality
B
maintenance
QA Sphere MCP server that enables Large Language Models to interact directly with test management system test cases, supporting AI-powered development workflows and test case discovery.
Updated a month ago (2026-07-21 22:57 UTC)
15
101
23
MIT
QTM4J MCP Server
Testing & QA Tools Project Management App Automation
salehrifai42
A
license
A
quality
B
maintenance
An MCP server that exposes the QMetry Test Management for Jira Cloud REST API as tools for MCP-compatible clients. It enables users to manage test cases, test cycles, test executions, test plans, folders, and automation rules through natural language interactions.
Updated 2 months ago (2026-06-11 04:28 UTC)
30
57
MIT
TestOps MCP Server
Testing & QA Tools Project Management
syn7xx
A
license
B
quality
A
maintenance
Enables AI assistants to interact with TestOps 5.25 for managing projects, test runs, test plans, and test cases via MCP tools.
Updated 2 months ago (2026-06-27 12:29 UTC)
31
49
MIT
test-case-generator-ai-mcp
Testing & QA Tools Developer Tools
CSOAI-ORG
A
license
Not graded
quality
A
maintenance
Enables generation of test cases, edge cases, and test matrices for software testing, integrated with MCP protocol and EU AI Act compliance.
Updated a month ago (2026-07-26 09:32 UTC)
3
MIT

View all related MCP servers

Related MCP Connectors

Qase Test Management
Official MCP server for Qase — manage test cases, runs, suites, defects via AI tools.
SmartBear MCP
MCP server for AI access to SmartBear tools, including BugSnag, Reflect, Swagger, PactFlow, QTM4J.
mcp
Your memory, everywhere AI goes. Build knowledge once, access it via MCP anywhere.

View all MCP Connectors

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sanumenon/qa-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server