Preview first. It changes nothing.
Check you are in range, preview read-only, read your survey, then adopt only if it convinced you. Adoption is a dependency and a build step, not a rewrite.
The gate comes first, before you invest anything.
A Spring Boot 2.x or Java 8 backend cannot host the runtime as-is, and we would rather tell you now than after you have edited your pom. The preview below, however, reads any Java source tree and needs only Java 17.
Survey your application. It reads source and writes nothing.
Download the self-contained CLI from Maven Central and point it at your application. This only reads source: it never writes to your project, never touches your build, and cannot break anything.
# Download the CLI jar from Maven Central (once): curl -O https://repo1.maven.org/maven2/io/github/tibyaan-org/tibyan-cli/0.2.0/tibyan-cli-0.2.0-jar-with-dependencies.jar # Survey your application. This only reads source; it writes nothing: java -jar tibyan-cli-0.2.0-jar-with-dependencies.jar scan /path/to/your-app
The CLI jar is published on Maven Central (io.github.tibyaan-org, v0.2.0).
It prints the discovered capabilities, every refusal with its located reason, and the totals including mis-bound 0. If the preview discovers nothing useful for your app, stop here: you have spent no build changes to learn it. You can also produce an OpenAPI 3.0 document from the same read-only model.
Prefer to build the CLI from source?
# From a checkout of the v0.2.0 tag (a main checkout builds a -SNAPSHOT jar): mvn -pl tibyan-cli -am -DskipTests package java -jar tibyan-cli/target/tibyan-cli-0.2.0-jar-with-dependencies.jar scan /path/to/your-app
Refusals are normal, and good. The number to watch is mis-bound.
A real, layered application turns into a precise verified subset plus a named ledger of refusals. That is the tool working, not failing. What each refusal means:
NO_BACKING_METHOD
No service method structurally backs this read, so nothing is exposed.
AMBIGUOUS_BINDING
Two or more methods both fit the shape of the read; the tool refuses rather than pick one.
NO_IDENTIFIER
The entity has no identifier that maps to a bindable primitive, so a read-by-id cannot be formed.
LIST_AMBIGUOUS
More than one list-all candidate exists; the tool will not choose between them.
Add --report survey.md to write the same survey as a shareable Markdown map. The one number that must stay 0 is mis-bound.
Two entries in your build file, then build.
Once the preview convinces you, add the runtime dependency, which hosts the MCP server inside your app's own context, and the build plugin, which generates the manifest from your source at build time.
<dependency> <groupId>io.github.tibyaan-org</groupId> <artifactId>tibyan-runtime-spring</artifactId> <version>0.2.0</version> </dependency>
<plugin>
<groupId>io.github.tibyaan-org</groupId>
<artifactId>tibyan-maven-plugin</artifactId>
<version>0.2.0</version>
<executions>
<execution>
<goals><goal>generate</goal></goals>
</execution>
</executions>
</plugin>The plugin is resilient by default: an unparseable source file is skipped and named at WARN, not fatal, so adopting Tibyaan does not break your build. Set -Dtibyan.strict=true to fail on any unparseable file for CI. Then build, and the plugin writes the manifest onto the classpath:
mvn package java -jar target/your-app.jar
Your discovered tools appear over MCP, calling your real methods.
The runtime finds the manifest on the classpath automatically: no launch property, no MCP block in application.yml. The MCP server is served at http://localhost:8080/sse. Point any client that speaks the HTTP and SSE transport at it; a stdio-only client such as Claude Desktop connects through a bridge.
curl -N http://localhost:8080/sse
Verified end to end: an out-of-process client completes initialize, tools/list, and a real tools/call over the network against the example app.
For the exact handshake, a scripted check, and the Claude Desktop bridge config, see Connecting an MCP client (opens in a new tab).
The endpoint runs real methods against real data. Gate it.
The generated server runs inside your application's process and calls your real service methods against your real data. v1 serves read-only capabilities: writes are refused at the discovery level, never generated into the manifest. But v1 adds no authentication of its own.
That makes network exposure your decision, and the most important one. Treat the endpoint like an unauthenticated admin console: bind it to localhost, or keep it behind your existing network controls, a VPN, or an authenticating reverse proxy you operate. The fail-loud discipline guarantees each tool is bound to the method that backs it; it does not authenticate callers or authorize actions. That decision is yours.
Read the security posture in full
The deep documentation, the seventeen design volumes and the dated benchmark ledgers, lives in the repository (opens in a new tab).