esekl
ESEKL — Empirical Software Engineering Knowledge Layer
ESEKL превращает результаты исследований production-grade open-source систем в набор структурированных инструментов, готовых к использованию агентами. Он доставляется как сервер Model Context Protocol (MCP). Это единственный подерживаемый способ доставки.
Агенты, рабоающие с распределенными системами — обработчиками очередей, брокерами соопщений, стриминг-паipelмами — сyстематически галлюцинируют повendческие контракты, искажают production-сценарии отказов и строят планы верификации без эмпирического основания. ESEKL устраняет этот разрыв. Он предоставляет знания с трассировкой происхождения и маркировкой сведетельств, полученные при механическом обзоре зрелых open-source систем, и раскрывает их через MCP-инструменты, заточенные под задачу, которые обещпечивают прогрессивное раскрытие вместо простого сброса контекста.
Текущий корпус покрывает системы очередей, брокеров и потоковой обработки: asynq, bullmq, pgmq, river, goqite, litequeue, nats-server, nsq, blazingmq, redpanda, rabbitmq, artemis и rocketmq.
Как это помогает агентам
Without ESEKL coding or planning agent, working with job queues, must either hallucinate behavioral contract or search through thousands of lines of source code to extract patterns. Both are impossible: галлюциGreek generate incorrect invariants; source browsing saturates the context window before the agent reaches required evidence.
ESEKL предоставляет:
Поведентские инварианты, извлеченныe прямым inspection of source code across the entire corpus, each marked with how it was derived (
SOURCE_OBSERVED,TEST_OBSERVED,HISTORY_SUPPORTED).Цепочки отказов from real production bugs and regression commits. /** with the exact commit hash and test function that closed them.
Implementation packets — exact SQL queries, Lua scripts and Go/TypeScript snippets extracted from production files — served with substrate and mechanism filters so that the agent gets exactly the class of implementation it aims for.
Критика проектируемых решений against cross-corpus invariants, uncovering missing fencing guarantees, clock-drift risks, and missing poison-job insulation in the proposed architecture.
Adversaриальные планы верификации, generated from empirical failure evidence, ready to launch the test suite.
Each result carries an epistemic label. Agents never allow a cross-repository abstraction for model inference.
Related MCP server: PactAI MCP
Architecture: how ESKUs are created
flowchart TD
A["Tier 0: Raw Codebase\n(factory/<repo>)"]
B["Tier 1: Atomic Observations\n(eku_middleware/eku_store/evidence/observations.json)\nExact file path, line range, verbatim snippet,\nlanguage, substrate"]
C["Tier 2: Repo-Local EKUs\n(eku_middleware/eku_store/repo_ekus/<repo>.json)\nConcrete mechanism, source snippet,\ntest provenance, failure provenance\nEpistemic: REPO_LOCAL"]
D["Tier 3: Domain EKUs\n(eku_middleware/eku_store/synthesized_queue_ekus.json)\nCross-repository behavioral invariants,\ndesign contracts, falsification audits\nEpistemic: DOMAIN_ABSTRACTION"]
E["MCP Server\n(esekl mcp)\nProgressively discloses\nTier 1-3 via 20 tools"]
F["Agent\n(Claude, Codex, AGY, etc.)"]
A -->|"Mechanical inspection\nAST + grep + test suite link"| B
B -->|"RepoEKU authoring\nvalidate_evidence_ledger.py"| C
C -->|"Cross-corpus synthesis\nClaim matrix + keyword groups"| D
D --> E
C --> E
B --> E
E -->|"JSON-RPC 2.0 / stdio"| FThe factory catalog contains commit-pinned checkout of the source repositories. Inspection is mechanical: source file paths, line ranges, verbatim snippets of code and names of test functions are recorded as Atomic Observations (Atomic Observations). These observations are grouped into Repo-Local EKUs — concrete, evidence-bearing records associated with a single repository — then synthesized upward into Domain EKUs, which carry cross-перечне behavioral invariants with explicit falsification audits. The MCP server reads the static store and exposes it through progressive disclosure tools. Agents interact only through these tools; they never touch the raw data.
The knowledge store (eku_store/) is supplied bundled inside the npm package. No initialization step is required. Configure MCP once, and on every machine that can run npx, the full corpus becomes immediately available.
Installation
No installation step is required.
The eku_store/ directory is directly bundled inside the esekl npm package. When npx esekl mcp starts, the server finds the store in the package directory — no local copy, no init, no per-project setup.
Connect the MCP server to your agentic host using one of the configurations below.
MCP Configuration
This single JSON block works on every machine, for any project, without code and without dependencies:
{
"mcpServers": {
"esekl": {
"command": "npx",
"args": ["-y", "esekl", "mcp"]
}
}
}Store resolution order (first match wins):
--store-root=<path>— with explicit override, for advanced use.~/.esekl/store— if a full offline or custom corpus was runesekl init.<package_dir>/eku_store— bundled in the package, always available, no setup needed.
Claude Desktop
Edit ~/.config/claude/claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/claude_desktop_config.json) and add the block above. Restart Claude Desktop.
AGY (Antigravity)
Add the block above to your AGY MCP config. No restart required for most AGY configurations.
Codex CLI
Add to ~/.codex/config.toml:
[mcp_servers.esekl]
command = "npx"
args = ["-y", "esekl", "mcp"]For Codex environments that accept the JSON mcpServers config, use the JSON block above.
Tool surface
The MCP server exposes 20 tools in three layers.
Search and Navigation (6 tools)
Tool | Required Arguments | Purpose |
| none | Corpus metadata: domain, total ESKUs, repositories, coverage ratios. |
| none | Paginated list of repository dossiers with language and storage engine filters. |
|
| A compact summary of key mechanisms and edge conditions for a single repository. |
| none | Cross-repository failure topics with related Domain EKU IDs. |
|
| Structured slice of the dossier: |
|
| Side-by-side comparison of two engines by mechanisms, invariants, and storage substrate. |
Evidence and Layered Retrieval (12 tools)
Tool | Required Arguments | Purpose |
|
| Multi-factor search across EKUs, claims, observations, and failures. |
|
| Full Domain EKU: behavioral invariant, design contract, verification contract, corpus statistics. |
| none | Paginated list of Repo-Local EKUs with mechanism and object type filters. |
|
| Full Repo-Local EKU with exact source lines, SQL/Lua snippet, and test suite provenance. |
| none | Cross-cutting keyword and substrate funnels of groups that associate Repo-Local EKUs. |
|
| Full keyword group with participating Repo-Local EKUs and linked Domain EKUs. |
|
| Down-traces a Domain EKU to its supporting Repo-Local EKUs, keyword groups, and raw observations. |
|
| Second-order failure patterns and vulnerability signatures associated with a problem description. |
| none | Causal failure chains: trigger, invariant breakdown, failure, status of regression test. |
| none | Dynamic implementation packets derived from Repo-Local EKUs, filtered by storage and mechanism. |
|
| Down-traces any ID to exact file path, line gap, hash-of-commit, hash of chunk SHA-256, and test. |
| none | Diagnostic audit across Repo-Local and Domain EKUs, exposing missing fields and broken references. |
Design Critique and Verification (2 tools)
Tool | Required Arguments | Purpose |
|
| Critiques the proposed architecture against empirical invariants, returning matched EKUs, missing guarantees, and "what not to promise" contracts. |
|
| Generates adversarial test suites related directly to empirical evidence and historical accidents. |
Result forms
{
"id": "EKU-QUEUE-015",
"title": "Fenced Domain Result Promotion & Outbox Emission",
"objectType": "BEHAVIORAL_INVARIANT",
"claimId": "CLM-015",
"problem": "A queue can fence stale completion of the job row while still allowing a superseded worker to write authoritative domain results or emit an outbox event.",
"behavioralInvariant": "Ownership fencing must guard every authoritative side-effecting state mutation, including domain result promotion or outbox emission, not only queue-row completion.",
"designContract": "Before committing a result row, payment ledger projection, or sendable outbox record, the storage transaction must prove current job ownership by token/generation.",
"verificationContract": [
"Worker A owns generation 1 and pauses.",
"Worker B owns generation 2 and completes.",
"Worker A attempts domain result promotion and queue completion.",
"Both stale writes affect zero authoritative rows and emit stale-owner telemetry."
],
"supportingEvidence": ["OBS-BULLMQ-002", "OBS-LITEQUEUE-002"],
"historicalEvidence": ["HIST-RIVER-003"],
"corpusStats": {
"corpusSize": 13,
"applicable": 7,
"supports": 2,
"counterexamples": 3
}
}{
"repoEku": {
"id": "REKU-RIVER-001",
"repository": "river",
"mechanism": "Relational Lock-Free Dequeue (FOR UPDATE SKIP LOCKED)",
"claim": "PostgreSQL FOR UPDATE SKIP LOCKED allows concurrent worker pools to acquire non-overlapping available jobs without table-level locking.",
"localContext": "River implements its primary job queue inside PostgreSQL. It relies on FOR UPDATE SKIP LOCKED in its sqlc query to scale Go worker goroutines.",
"sourceProvenance": {
"filePath": "riverdriver/riverpgxv5/internal/dbsqlc/river_job.sql",
"lineRange": [45, 55],
"queryOrCodeSnippet": "SELECT id, args, attempt, state FROM river_job WHERE state = 'available' ORDER BY priority ASC, scheduled_at ASC LIMIT $1 FOR UPDATE SKIP LOCKED;"
},
"testProvenance": {
"filePath": "internal/jobexecutor/job_executor_test.go",
"testName": "TestJobExecutor"
},
"epistemicStatus": "REPO_LOCAL"
}
}{
"evidenceId": "OBS-BULLMQ-002",
"type": "OBSERVATION",
"repository": "taskforcesh/bullmq",
"commitHash": "c06b51cd3aacd0d9ee65e2544220c89f24d2479c",
"filePath": "src/commands/moveToFinished-12.lua",
"lineRange": { "start": 40, "end": 44 },
"sourceUrl": "https://github.com/taskforcesh/bullmq/blob/c06b51cd3aacd0d9ee65e2544220c89f24d2479c/src/commands/moveToFinished-12.lua#L40-L44",
"snippetSha256": "4b68e98da6984e1b00ad99e74d1c448bb5bbcb110cb16246473133604f32616f",
"epistemicStatus": "SOURCE_OBSERVED"
}{
"matchingEkus": ["EKU-QUEUE-015", "EKU-QUEUE-016", "EKU-QUEUE-017"],
"missingInvariants": [
{
"invariant": "Storage-Time Lease Evaluation",
"severity": "CRITICAL",
"risk": "Caller-supplied VM timestamps allow clock drift across container hosts to cause premature lease expiration or duplicate execution.",
"recommendedFix": "Use database server time (e.g. clock_timestamp()) exclusively in lease recovery queries."
}
],
"whatNotToPromise": [
"Never promise true exactly-once delivery over external network boundaries without partner idempotency keys.",
"Never promise constant latency during unmetered enterprise batch spikes; enforce admission semaphores and HTTP 429/503."
],
"epistemicClassification": {
"empiricalEvidenceCount": 8,
"modelInferredPoints": 2
}
}Repository structure
eku_middleware/ npm package root (published as esekl)
bin/ CLI and MCP server entry points
src/ MCP server implementation
eku_store/ Static knowledge store — ships bundled inside the package
evidence/ Atomic observations and historical failure records
repo_ekus/ Repo-Local EKUs per repository
synthesized_queue_ekus.json Cross-corpus Domain EKUs
claim_matrix.json Claim-to-corpus coverage matrix
schema/ JSON schema and specification for RepoEKUs
release/ factory_repo_lock.json — commit-pinned source provenance
mcp_contract.md Full JSON-RPC contract with input/output schemas
analyzer/ Validation scripts (not shipped in npm package)
factory/ Local raw repository cache for research rounds (git-ignored)Epistemic labels
All tool results are accompanied by explicit labels. Agents should not remove or ignore them.
Label | Value |
| Direct mechanical inspection of production source files and AST structures. |
| Direct study of regression test suites in the target repository. |
| A confirmed real production incident, bugfix, or issue commit. |
| Architecture documentation or official specification statement. |
| High-level inference formulated from observations. |
| A general behavioral property proven in two or more code codebases. |
| Actionable architectural guidance derived from empirical invariants. |
Full MCP contract
Complete input and output schemas for all 20 tools.
This server cannot be deployed
Maintenance
Related MCP Connectors
Shared, peer-validated knowledge archive for AI agents — search, contribute, and validate via MCP
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.
Experimental MCP for discovering and purchasing explicitly published, versioned Agent knowledge.
Team docs served to AI agents over MCP - search, Markdown reads, version pinning, read audit.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to search code by meaning, explore codebase structure, store and query knowledge with temporal facts, and read source code through a set of MCP tools.310 npm7MIT
- AlicenseNot gradedqualityBmaintenanceServes coding agents with project-specific knowledge (decisions, conventions, constraints) over MCP and provides verification verdicts on whether code still complies.365 npmAGPL 3.0
- AlicenseNot gradedqualityAmaintenanceAn MCP server that enables verified agents to retrieve from, propose changes to, and share capabilities around a human-owned Markdown/Git knowledge base, ensuring curation, exact-byte approval, and Git-based promotion.MIT
- AlicenseNot gradedqualityAmaintenanceEnables MCP agents to maintain durable, evidence-aware project knowledge, retrieve precise excerpts on demand, and track decisions, conflicts, and revisions across sessions.1Apache 2.0