Skip to main content
Glama
deenesjakoruzh
sanumenon

QA MCP Server

by sanumenon
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

QA MCP Server

Ein erweiterbarer Model Context Protocol (MCP)-Server, der zu einer einheitlichen KI-gestützten QA-Plattform werden soll.

Aktueller Status

Phase 1 — Grundlage & QA-Intelligenz

ABGESCHLOSSEN

Schritt

Funktion

Status

1

Projektgrundlage

ABGESCHLOSSEN

2

MCP-Server + Health-Check

ABGESCHLOSSEN

3

LLM-Anbieter-Abstraktion

ABGESCHLOSSEN

4

Anforderungsanalysator

ABGESCHLOSSEN

5

Testfallgenerator

ABGESCHLOSSEN

6

Testfallprüfer

ABGESCHLOSSEN

7

End-to-End-QA-Workflow

ABGESCHLOSSEN

Phase 2 — Projektkontext, Persistenz, Versionierung & Portabilität

Schritt

Funktion

Status

1

QA-Projektkontext

ABGESCHLOSSEN

2

SQLite-Persistenz

ABGESCHLOSSEN

3

QA-Suite-Versionierung

ABGESCHLOSSEN

4

Import / Export

ABGESCHLOSSEN

1. Vision

Das langfristige Ziel ist es, eine wiederverwendbare QA-MCP-Plattform zu entwickeln, die QA-Funktionen für MCP-kompatible KI-Clients bereitstellt.

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-Architektur

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

Kern-MCP-Funktionen:

analyze_requirement
generate_test_cases
review_test_cases
generate_qa_suite

3. LLM-Architektur

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

Der LLM-Zugriff ist anbieterunabhängig, sodass die QA-Tools lokal getestet und später mit AWS Bedrock oder einem anderen Anbieter verbunden werden können.

KI-Ausgaben werden vor der Weiterverarbeitung mithilfe von Pydantic-Modellen validiert.

4. Phase 2 Schritt 1 — QA-Projektkontext

Status: ABGESCHLOSSEN

Ein QA-Projekt enthält:

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

Kernservice:

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

MCP-Tools:

create_qa_project
get_qa_project

5. Phase 2 Schritt 2 — SQLite-Persistenz

Status: ABGESCHLOSSEN

Projekte werden persistiert in:

data/qa_mcp.db

SQLite-Tabelle:

qa_projects

Architektur:

ProjectContext
       |
       v
ProjectRepository
       |
       v
SQLiteProjectRepository
       |
       v
SQLite

Der Kernkontext hängt nicht direkt von SQLite ab.

Die Persistenz wurde über separate Python-Prozesse hinweg verifiziert.

6. Phase 2 Schritt 3 — QA-Suite-Versionierung

Status: ABGESCHLOSSEN

QA-Anforderungen und generierte Suiten werden unabhängig voneinander versioniert und persistiert.

Related MCP server: QTM4J MCP Server

Anforderungsversionen

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

Jede Anforderungsversion enthält:

  • version_id

  • project_id

  • version

  • requirement

  • application

  • environment

  • created_at

Versionen werden pro Projekt unabhängig verwaltet.

Suite-Versionen

Jede Suite erfasst die Anforderungsversion, die sie erzeugt hat:

Requirement v1
      |
      v
Suite v1

Requirement v2
      |
      v
Suite v2

Jede Suite-Version enthält:

  • suite_id

  • project_id

  • requirement_version_id

  • version

  • test_cases

  • review

  • created_at

Architektur

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

Die beiden versioning-Ordner sind beabsichtigt:

  • core/versioning enthält die Geschäftslogik.

  • infrastructure/versioning enthält Repository-Schnittstellen und SQLite-Implementierungen.

Kernservices

QARequirementVersioningService
QASuiteVersioningService

Repository-Schnittstellen

RequirementVersionRepository
SuiteVersionRepository

SQLite-Implementierungen

SQLiteRequirementVersionRepository
SQLiteSuiteVersionRepository

MCP-Tools

Anforderung:

create_requirement_version
get_requirement_version
list_requirement_versions

Suite:

create_suite_version
get_suite_version
list_suite_versions

7. Phase 2 Schritt 4 — Import / Export

Status: ABGESCHLOSSEN

Der QA-MCP-Server unterstützt jetzt portable Projektartefakte, die Folgendes enthalten:

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

Export

Der Exportablauf ist:

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

Der Export basiert auf persistierten Daten, nicht auf vom Aufrufer zusammengestellten Objekten.

MCP-Tool:

export_qa_project

Eingabe:

project_id

Ausgabe:

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

Import

Der Importablauf ist:

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

MCP-Tool:

import_qa_project

Der Import validiert:

  • Export-JSON

  • Exportstruktur

  • Projektidentität

  • Beziehung Anforderung → Projekt

  • Beziehung Suite → Projekt

  • Beziehung Suite → Anforderungsversion

  • Schutz vor doppelten Projekten

Vorhandene Projekte werden nicht stillschweigend überschrieben.

Round-Trip-Verifizierung

Der vollständige Round-Trip wurde verifiziert:

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

Verifizierte Artefakte:

Project           ✅
Requirements      ✅
Suites            ✅
Relationships     ✅

Test-Isolation

MCP-Import-/Export-Tests verwenden isolierte temporäre SQLite-Datenbanken.

Dies verhindert, dass die Testausführung Folgendes verunreinigt:

data/qa_mcp.db

und ermöglicht die wiederholte Testausführung, ohne sich auf einen früheren Testzustand zu verlassen.

P2-S4-Verifizierungs-Baseline

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

Die verbleibende Warnung ist die bekannte externe pydantic_settings-Warnung bezüglich der unaufgelösten Vorwärtsreferenz des lifespan-Felds.

8. Projektstruktur

Aktuelle wichtige Quellstruktur:

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. Lokale Einrichtung

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

Tests ausführen:

pytest -q

Aktuell verifizierte Baseline:

49 passed

Den MCP-Server ausführen:

python -m qa_mcp.server

Serverimporte verifizieren:

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

10. Entwicklungsrichtlinien

Wir befolgen diesen Workflow für jeden Implementierungsschritt:

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

Regeln:

  1. Implementiere einen Schritt nach dem anderen.

  2. Teste jede Funktion.

  3. Bestehende Tests müssen grün bleiben.

  4. Kein Schritt ist abgeschlossen, bis er lokal verifiziert wurde.

  5. Aktualisiere die README bei jedem verifizierten Meilenstein.

  6. Die Kern-Geschäftslogik muss unabhängig vom MCP-Transport bleiben.

  7. Persistenz und externe Integrationen bleiben hinter Schnittstellen.

  8. LLM-Anbieter bleiben austauschbar.

  9. KI-Ausgaben müssen validiert werden.

  10. Tests müssen gegenüber persistentem Speicher wiederholbar bleiben.

  11. Lösche keine persistenten Datenbanken, nur um Tests bestehen zu lassen.

  12. Verwende isolierte Datenbanken für persistenzorientierte Tests.

  13. Kopiere keine Assistentenkonversation manuell in die README.

  14. Die README ist der maßgebliche Entwicklungs-Checkpoint.

  15. Keine größere Funktion ist abgeschlossen, bis ihr MCP-/Laufzeitpfad verifiziert ist.

11. Architekturprinzipien

  1. Die Kern-Geschäftslogik gehört in core.

  2. Die Persistenz gehört in infrastructure.

  3. Der MCP-Transport gehört in server.py und in MCP-orientierte Tools.

  4. Domänen-/Datenmodelle gehören in models.

  5. Kernservices dürfen nicht direkt von SQLite-Implementierungen abhängen.

  6. Externe Integrationen müssen hinter Schnittstellen isoliert sein.

  7. LLM-Anbieter bleiben austauschbar.

  8. KI-generierte Ausgaben müssen vor der Weiterverwendung validiert werden.

  9. Persistente Daten dürfen nicht mit Test-Fixtures verwechselt werden.

  10. Tests müssen wiederholbar sein.

  11. Importvorgänge müssen Beziehungen vor der Persistenz validieren.

  12. Importe dürfen vorhandene Projekte nicht stillschweigend überschreiben.

  13. Abgeschlossene Meilensteine erfordern eine Regressionsverifizierung.

  14. README-Aktualisierungen sind Teil des Meilensteinabschlusses.

12. Phase-2-Roadmap

Schritt

Funktion

Status

1

QA-Projektkontext

ABGESCHLOSSEN

2

SQLite-Persistenz

ABGESCHLOSSEN

3

QA-Suite-Versionierung

ABGESCHLOSSEN

4

Import / Export

ABGESCHLOSSEN

5

Jira-Konnektor

ALS NÄCHSTES

6

Jira → QA-Workflow

GEPLANT

7

Automatisierungsfall-Generator

GEPLANT

8

QA-Agent

GEPLANT

9

GitHub / CI-Integration

GEPLANT

10

Internet-Bereitstellung

GEPLANT

13. Geplante endgültige Architektur

                    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. Aktuelle 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

Aktuelle Verifizierung:

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

Bekannte Warnung:

pydantic_settings
IncompleteFieldDefinitionWarning
Field 'lifespan'

Dies ist eine Warnung zu einer externen Abhängigkeit und blockiert derzeit weder Funktionalität noch Tests.

15. Nächster Entwicklungsschritt

Phase 2 → Step 5
       |
       v
Jira Connector

Die nächste Implementierungsphase sollte erst beginnen, nachdem dieser README-Checkpoint festgehalten wurde.

16. Meilenstein-Historie

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

Diese README repräsentiert den Projektstand nach erfolgreicher Verifizierung von Phase 2 → Schritt 4 — Import / Export.

This server cannot be installed

F
license - not found
Not graded
quality - not tested
C
maintenance

How are these scores calculated?

Maintenance

–Maintainers
–Response time
–Release cycle
–Releases (12mo)
Commit activity

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Servers

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

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