ariadne mcp-server
The ariadne MCP server helps AI agents identify which Kotlin tests are affected by code changes, enabling smarter, targeted test runs during development.
Key capabilities:
Get affected tests (
get_affected_tests): Analyzes a Kotlin project and returns a sorted list of fully qualified test names (FQNs) impacted by current code changes (e.g.,com.example.UserServiceTest.testCreateUser)Automatic git diff: Internally runs
git diff— no need to pass diffs manually; requires an absolute path to the Kotlin project rootDeep and shallow scopes:
deepanalyzes all changes since a base branch (committed + uncommitted);shallowanalyzes uncommitted changes only, suited for tight edit loopsBase branch selection: Specify a base branch to compare against (defaults to
origin/mainfor deep scope)Safety warnings: If unanalyzable changes are detected (e.g., build scripts, resources), a note is appended recommending a full test run
Timeout handling: Analysis is bounded by a 120-second timeout, returning an explicit error if exceeded
Static analysis powered: Uses the
sazanamilibrary and Kotlin Analysis API for accurate call-graph-based dependency analysisMCP-compatible: Works with MCP clients such as Claude Code and Claude Desktop
ariadne is an MCP (Model Context Protocol) server that provides AI agents with the ability to identify affected tests. Powered by sazanami, it analyzes code changes and returns only the tests that need to be run.
⚠️ MUST READ: Speed over Completeness
ariadne is built for the agent inner loop — edit, verify, commit — where fast feedback matters more than exhaustive selection. Static analysis cannot trace every execution path: reflection, DI frameworks, and data-flow indirection (e.g., Flux/MVI dispatch) can hide dependencies from any affected-test-selection tool, not just ariadne.
Always keep a final line of defense in CI. Run the full test suite (or a conservative selection) before merging. ariadne narrows what an agent runs while iterating; it is not a replacement for CI.
When ariadne detects changes it cannot analyze (build scripts, resources, unscanned source sets), it says so explicitly in the tool response instead of silently reporting "no affected tests".
Related MCP server: octopilot-mcp
Features
MCP Integration — Works with Claude Code, Claude Desktop, and other MCP-compatible clients
Automatic Git Diff — No need to pass diff manually; ariadne runs
git diffinternallyPowered by sazanami — Uses Kotlin Analysis API for accurate static analysis
Installation
Homebrew (recommended)
brew install mikhailhal/tap/ariadneThen register it with your MCP client — for Claude Code:
claude mcp add ariadne -- ariadneOr add to your MCP client configuration manually (e.g., Claude Desktop):
{
"mcpServers": {
"ariadne": {
"command": "ariadne"
}
}
}Docker
docker run -i --rm -v /path/to/project:/workspace ghcr.io/mikhailhal/ariadneMount the project you want analyzed and pass /workspace as project_path.
The image is also listed in the official MCP Registry as io.github.MikhailHal/ariadne.
Manual (release JAR)
Download ariadne-<version>-all.jar from Releases (requires JDK 21+) and configure your client with "command": "java", "args": ["-jar", "/path/to/ariadne-<version>-all.jar"].
Build from Source
git clone --recursive https://github.com/MikhailHal/ariadne.git
cd ariadne
./gradlew shadowJar # fat JAR: build/libs/ariadne-<version>-all.jarUsage
Once configured, AI agents can use the get_affected_tests tool:
Tool: get_affected_tests
Parameters:
project_path(required) — Path to the Kotlin projectscope(optional,deep|shallow, defaultdeep) — how far back to look:deep— all changes sincebase_branch(committed and uncommitted). Safest; the whole branch is covered so nothing you already committed slips through unverified. May select more tests.shallow— uncommitted changes only (diff againstHEAD). Fastest, for the tight edit loop. Verifying already-committed work is left to the caller.base_branchis ignored.
base_branch(optional,deepscope only) — Branch to compare against. When omitted, ariadne uses the repository's default branch (origin/HEAD). If that is not set (e.g. a repo with no remote), it returns an error asking you to passbase_branchexplicitly rather than guessing.
Returns:
List of affected test FQNs (fully qualified names), sorted
If the diff contains changes outside the analyzed Kotlin sources (build scripts, resources, unscanned source sets), a note is appended recommending a full test run for those changes
Analysis is bounded by a 120s timeout; on timeout an explicit error is returned
Example
Agent request:
{
"name": "get_affected_tests",
"arguments": {
"project_path": "/path/to/your/kotlin/project"
}
}Response:
com.example.UserServiceTest.testCreateUser
com.example.UserRepositoryTest.testSaveHow It Works
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ MCP Client │ ──▶ │ ariadne │ ──▶ │ sazanami │
│ (Agent) │ │ (MCP Server)│ │ (Analysis) │
└─────────────┘ └─────────────┘ └─────────────┘
│
▼
┌─────────────┐
│ git diff │
└─────────────┘Agent calls tool — Passes project path to ariadne
Run git diff — ariadne executes
git diff --unified=0against base branchAnalyze with sazanami — Build call graph and find affected tests
Return results — List of test FQNs returned to agent
Real-World Validation: Now in Android
Measured against Now in Android (Google's reference Android app — 34 modules, ~268 Kotlin files):
Metric | Result |
Recall audit — 19 target functions across all layers | 18/18 valid targets detected (the 19th had no exercising unit test; correctly not selected) |
End-to-end response time | ~4s (module discovery + call-graph build + BFS) |
Module discovery | 34 modules via |
Source sets |
|
Verified patterns include repositories behind project interfaces, a library-interface
override (androidx.datastore.Serializer), operator fun invoke use cases,
@Composable functions, extension mappers, ViewModel property-initializer chains,
and callable references. Two representative results:
Changing
core:common'sasResult()selects 14 tests across three modules, including ViewModel tests reachable only throughval uiState = ...stateIn(...)Changing the mapper
PopulatedNewsResource.asExternalModel()selects 14 tests, including 11 repository tests reachable only through.map(Type::mapper)chains
Test-class selection rate
Every unit-test class in Now in Android was measured by changing a function in the class it tests and checking whether that test class was selected:
Test style | Selected |
Plain unit tests (construct the object, call it) | 13 / 13 valid targets |
Robolectric / Compose screenshot tests | 12 / 12 |
Framework-dispatched callbacks (lint | 0 / 2 — see below |
Robolectric turned out not to be a barrier: those tests call the composable
themselves (setContent { NiaTheme { ... } }), so the call exists in the source.
What decides coverage is not the test runner but whether the test's own code
contains the call.
What ariadne cannot see
The rule of thumb: if the framework calls your code instead of your test calling it, ariadne cannot connect them. These are limits of static analysis, not bugs — plan your CI safety net around them:
Pattern | Status |
Framework-invoked callbacks — Fragment/Activity lifecycle ( | Not traced: no call written in the test |
Reflection / DI-container wiring | Not traced |
UDF dispatch (Flux/MVI) |
|
| Covered — verified with exact selection |
Instrumented tests ( | Out of scope by design |
Build scripts, resources, unscanned source sets | Not analyzed — reported explicitly in the tool response |
Same-name top-level extensions in one package | Over-selected (receiver types are not part of top-level FQNs) — safe direction |
KMP source sets ( | Enumerated, but resolution quality unverified (#1) |
Full audit notes: sazanami#29, sazanami#38.
Requirements
JDK 21 or later
Git — For diff detection
Limitations
Module discovery is convention-based: it parses
settings.gradle(.kts)includes, enumeratessrc/<sourceSet>/{kotlin,java}layouts, and readsproject(":x")/ type-safe accessor dependencies from build files. Dynamic includes,projectDirremapping, customsrcDirs, and dependencies injected by convention plugins are not detected — see #1Full graph rebuild on each request (no caching yet); analysis is capped at 120s
See What ariadne cannot see for analysis-level gaps
License
Copyright 2025 ariadne contributors
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0See LICENSE for the full text.
Available Tools
1 toolget_affected_testsA
Get tests affected by code changes. Automatically runs git diff (including uncommitted changes) and analyzes which tests need to be run. Returns a sorted list of test FQNs (fully qualified names). If the diff contains changes outside the analyzed Kotlin sources (build scripts, resources), a note is appended — consider running the full test suite for those changes.
| Name | Required | Description | Default |
|---|---|---|---|
| base_branch | No | Git branch to compare against (default: origin/main) | |
| project_path | Yes | Absolute path to the Kotlin project root directory |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description fully discloses the tool's behavior: it automatically runs git diff including uncommitted changes, analyzes which tests are affected, returns sorted FQNs, and appends a note for non-Kotlin changes. This is comprehensive and transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two well-structured sentences. The first sentence states the purpose, and the second adds critical operational detail without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all essential aspects: what the tool does, how it works (git diff), what it returns (sorted FQNs), and edge-case behavior (notes for non-Kotlin changes). No output schema exists, but the return value is described adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter schema coverage is 100%, so the description neither adds nor detracts from schema information. The description does not elaborate on parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb-object phrase 'Get tests affected by code changes' and elaborates with specific details about running git diff and analyzing tests, leaving no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides usage by mentioning that it runs git diff on uncommitted changes and returns sorted FQNs. It also provides a note about when to consider running the full test suite (for changes outside Kotlin sources), which serves as an implicit usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
With only one tool, there is no ambiguity. The tool's name and description clearly define its single purpose.
The tool name follows a descriptive verb_noun pattern ('get_affected_tests'), which is consistent with typical MCP naming conventions.
A single tool is borderline for most servers; while it serves a narrow purpose, additional tools for related operations (e.g., running tests) would be expected.
The tool only covers detection of affected tests, but lacks complementary operations like listing all tests, running tests, or configuring the analysis, leaving significant gaps.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
A Model Context Protocol server for Wix AI tools
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
MCP server for building and testing AI agents with multi-model experimentation and insights.
Related MCP Servers
- AlicenseBqualityBmaintenanceLocal MCP server providing project cognition capabilities for AI coding agents, including context packs, impact analysis, and git diff review through stdio communication.103MIT

octopilot-mcpofficial
FlicenseAqualityDmaintenanceModel Context Protocol (MCP) server for Octopilot — enables AI agents to detect, generate, build, and wire up new repositories end-to-end using the Octopilot CI/CD toolchain.7- AlicenseNot gradedqualityAmaintenanceMCP server for test impact analysis and code intelligence. Maps tests to code and git history to determine impacted tests, risk scores, and ownership for AI coding agents.2MIT
- AlicenseNot gradedqualityAmaintenanceMCP server for local-first code intelligence, providing structural code graph, semantic search, and impact analysis to AI agents.2MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/MikhailHal/ariadne'
If you have feedback or need assistance with the MCP directory API, please join our Discord server