DEV Community: Atanas Oreshkov

Give your AI agent the real sources of any Kotlin/Java library

Atanas Oreshkov — Thu, 23 Jul 2026 20:02:14 +0000

Your AI coding assistant will confidently hand you a Kotlin method signature that does not exist. For a strongly-typed ecosystem, "plausible but wrong" is the worst failure mode — it compiles in your head and breaks in the build.

Here's it reading the real sources instead:

One prompt. kotlin-lib-mcp downloaded Ktor's sources jar, parsed it with the Kotlin Analysis API (the same K2/FIR front-end that powers the IDE), and answered from the actual code.

One coordinate, ten tools

fetch_library("io.ktor:ktor-client-core:3.5.1")

That's the whole setup. The server downloads the sources jar, extracts it, analyzes it once, and caches the parsed index on disk. Your agent then has ten tools over it:

list_packages / list_declarations — the public API surface
get_api_signature — a type-resolved signature (generics, nullability, receiver)
get_kdoc — KDoc as structured data, not an HTML page
get_source / search_source — the real implementation + bounded search
get_dependencies — the dependency tree from .pom / .module
list_versions / get_latest_version — resolve "latest stable" from Maven metadata

Pinned to the exact version you depend on, offline after the first fetch. No drift between "the docs" and the version in your build.

Why "resolved" is the whole point

Regex over source gives you a signature-shaped string. The Analysis API actually ran the compiler front-end — so you get the resolved type, not a guess. When a transitive dependency is missing it degrades to a best-effort PSI signature and flags it bestEffort: true, instead of failing. Graceful degradation over an empty answer.

Two Kotlin-specific things made this more than "unzip a jar":

KMP sources jars are per-target. A Multiplatform library publishes -jvm-sources.jar, a common one, and so on — resolved via .module Gradle metadata, with every symbol tagged by target.
The Analysis API is version-fragile. Standalone mode must be version-locked to the exact Kotlin release, so it's quarantined behind one SourceAnalyzer interface.

Try it in ~60 seconds

Docker, no build required:

claude mcp add kotlin-lib -- docker run -i --rm -v kotlin-lib-mcp-cache:/home/mcp/.cache ghcr.io/aoreshkov/kotlin-lib-mcp

Or grab the release zip (Java 21+), or install from the official MCP registry as io.github.aoreshkov/kotlin-lib-mcp. Then ask your agent to fetch a library and explain an API — it answers from the code.

It's also a tidy reference build: all three MCP primitives (tools, resources per cached library + a resource template, and a prompt), plus per-tool behavior annotations, typed outputSchema, progress notifications, and server→client log forwarding. Built on the current stable MCP spec (2025-11-25); the 2026 roadmap's stateless core and Tasks/Apps extensions are the natural next step.

GitHub: https://github.com/aoreshkov/kotlin-lib-mcp — Apache-2.0. Analysis-API edge cases especially welcome.

Enjoyed this? I also wrote about generating a full Kotlin Multiplatform app in one dialog.

Generate a production-grade Kotlin Multiplatform app (Compose, Room 3, Navigation 3, Koin) in one dialog

Atanas Oreshkov — Mon, 20 Jul 2026 20:54:23 +0000

Generate a production-grade Kotlin Multiplatform app (Compose, Room 3, Navigation 3, Koin) in one dialog

Starting a Kotlin Multiplatform project has a strange cost curve. The first Hello, world is cheap — the IDE's built-in wizard gives you a shared module and platform targets in a minute. The next two weeks are where the real setup lives: choosing an architecture, wiring a KMP-ready database, getting type-safe navigation working, setting up DI without service-locator soup, structuring Gradle so the build doesn't rot, and writing enough tests to trust any of it.

This article walks through one opinionated answer to that setup — the architecture decisions themselves, and why they're baked the way they are. The vehicle is KMP Project Wizard, an open-source IntelliJ IDEA / Android Studio plugin I built that generates the whole thing from File → New Project, but every decision below stands on its own — you can apply them by hand to any KMP codebase.

The reference-app principle: templates that can't go stale by construction

The most important decision isn't in the generated code at all. The templates aren't hand-authored files that drift out of date — they're generated from kmp-ledger, a real, working, MIT-licensed double-entry ledger app that builds, tests, and runs on all three platforms. At plugin build time, concrete names (app.oreshkov.ledger, Posting, Ledger) are replaced with placeholders; at generation time, your names are substituted back in — package, app name, feature name, entity fields, everywhere including directory names.

The consequence: if the reference app compiles and its tests pass, so does your generated project. "Template rot" — the classic starter-kit disease — becomes a build failure in my pipeline instead of a runtime surprise in your project.

Architecture: Clean layers with a feature API/impl split

The generated project is modular from the first commit:

Domain / Data / UI layers per feature, with the dependency arrow always pointing inward — UI and Data both depend on Domain; Domain depends on nothing.
A feature API/impl split: each feature exposes a small api module (public contracts) and keeps its impl private. Other features depend on api only, so feature boundaries survive growth and builds stay parallelizable.
Binary-compatibility validation: the Kotlin BCV plugin's apiDump snapshots every module's public ABI, and apiCheck fails the build when a public contract changes accidentally. (A detail I got wrong the first time: ABI dumps are compiler-output snapshots — symbol names, declaration order, and Compose lambda keys derive from your names, so shipping the reference app's dumps with names substituted can never match. The wizard instead runs apiDump after your project's first Gradle sync, so the baseline is generated from your code.)

The stack, and why each piece

Compose Multiplatform for shared UI across Android, iOS, and Desktop — one rendering model, platform entry points kept thin.
Navigation 3 for type-safe routing: destinations are serializable types, not string routes, so a refactor that breaks navigation breaks the compile.
Room 3 for persistence — the KMP-ready generation of Room, meaning the same DAO and entity definitions run on all targets, with SQLite under the hood.
Koin + KSP annotations for DI: annotation-driven definitions with compile-time processing, no reflective magic on the hot path, and no hand-maintained module lists.
Coroutines & Flow end to end — repositories expose Flow, use cases suspend, UI collects with lifecycle awareness.

Gradle that scales: convention plugins + version catalog

All build logic lives in convention plugins (build-logic/), applied by module type — a feature impl module's build file is a few lines naming its type and dependencies. Versions are centralized in gradle/libs.versions.toml. Adding a fifteenth module costs the same as adding the second, and a dependency bump is a one-line change.

Tests as part of the template

Every generated project ships a passing suite: unit tests for domain and data (including an in-memory Room setup) and Compose UI tests. Not because sample tests are valuable in themselves, but because a testing pattern you can copy beats a blank src/test directory every time you add a feature.

What the one dialog actually asks

Package name, app name, one feature name, one entity with a test value, and target platforms (Android / iOS / Desktop). From that it derives every identifier — PascalCase types, camelCase members, snake_case resources — and renders the whole tree with your names, then triggers Gradle sync and generates the ABI baselines.

The plugin's core is free (all three platforms, the full architecture and tests). A paid Pro tier adds two things to the generated project: Claude Code agent config (CLAUDE.md, .claude/ skills) and GitHub Actions CI (.github/) — flat files, no runtime services, and the same content you can inspect in kmp-ledger.

DEV Community: Atanas Oreshkov

Give your AI agent the real sources of any Kotlin/Java library

One coordinate, ten tools

Why "resolved" is the whole point

Try it in ~60 seconds

Generate a production-grade Kotlin Multiplatform app (Compose, Room 3, Navigation 3, Koin) in one dialog

Generate a production-grade Kotlin Multiplatform app (Compose, Room 3, Navigation 3, Koin) in one dialog

The reference-app principle: templates that can't go stale by construction

Architecture: Clean layers with a feature API/impl split

The stack, and why each piece

Gradle that scales: convention plugins + version catalog

Tests as part of the template

What the one dialog actually asks

Links