llm-eval-mcp

Un serveur MCP (Model Context Protocol) qui expose des outils d'évaluation de fiabilité pour les agents LLM : génération de tâches adversariales, jugement automatisé (LLM-as-judge) et statistiques de confiance.

État : Bloc 4 — trois outils MCP, persistance (SQLite/PostgreSQL), conteneurisation Docker (build multi-étapes) et CI GitHub Actions (lint + tests à chaque push). Le bloc suivant ajoutera le transport HTTP distant, l'authentification et le déploiement en production.

Architecture

src/llm_eval_mcp/
├── domain/                 # Logique métier PURE (aucun réseau, aucun fournisseur, aucun SQL)
│   ├── adversarial.py      #   génération de tâches adversariales
│   ├── judging.py          #   verdict, contrat `Judge`, rubrique, orchestration
│   └── eval_run.py         #   entité EvalRun, contrat `EvalRunRepository`, stats
├── adapters/               # Détails techniques (réseau, fournisseurs, base de données)
│   ├── groq_judge.py       #   implémentation réelle du juge (Groq)
│   └── persistence.py      #   implémentation réelle du repository (SQLAlchemy)
└── server.py               # Fine couche MCP : publie le domaine en outils + câblage
tests/
├── test_adversarial.py     # Tests du générateur
├── test_judging.py         # Tests du jugement (FAUX juge)
├── test_groq_judge.py      # Tests de l'adaptateur Groq (faux client)
├── test_persistence.py     # Tests stats + repo SQL (SQLite) + intégration serveur
└── fakes.py                # Doublures de test (FakeJudge, InMemoryEvalRunRepository)

Mêmes principes partout : le domaine ignore MCP, le fournisseur LLM ET la base de données. Les adaptateurs isolent les détails. Grâce aux contrats Judge et EvalRunRepository (injection de dépendance), les tests tournent avec des doublures — sans clé, sans réseau, sans base — de façon déterministe.

Related MCP server: groundcheck

Configuration

Le juge a besoin d'une clé Groq (gratuite, sans carte, sur https://console.groq.com) :

cp .env.example .env        # puis colle ta clé dans GROQ_API_KEY

Base de données : par défaut un fichier SQLite local (eval_runs.db, ignoré par Git). En production, définir DATABASE_URL vers un PostgreSQL — le code ne change pas. Pour le driver PostgreSQL : pip install -e ".[postgres]".

Évolution du schéma : ce MVP crée les tables au démarrage. En production sérieuse, on gérerait les migrations avec Alembic (next step).

Installation

python -m venv .venv
source .venv/bin/activate        # Windows : .venv\Scripts\activate
pip install -e ".[dev]"

Lancer les tests

pytest

Lancer le serveur

Le serveur parle le transport stdio : il ne s'utilise pas « à la main », mais via un client MCP. Le plus simple pour l'inspecter :

mcp dev src/llm_eval_mcp/server.py

Cela ouvre MCP Inspector dans le navigateur : on y voit l'outil generate_adversarial_tasks, on le liste et on l'appelle interactivement.

Docker

Image de production construite en multi-étapes (l'image finale ne contient ni les outils de build ni les caches), tournant sous un utilisateur non-root.

docker build -t llm-eval-mcp .
docker run --rm -i --env-file .env llm-eval-mcp

Intégration continue (CI)

À chaque push et pull request, GitHub Actions installe le projet, lance le linter (ruff) et les tests (pytest) sur une machine propre. Aucun secret n'est requis : les tests utilisent les doublures (FakeJudge, InMemoryEvalRunRepository), donc ni clé API ni base de données.

Licence

MIT.