One verified map. Many outputs. Nothing guessed.
Tibyaan reads the Spring backend you already run, proves which read operations are safe to expose, and serves them to agents in place, without touching your code. The rest of this page is how.
It builds one neutral description, and generates everything from it.
Tibyaan reads your source and writes down the business objects it finds and the read operations over them, in a form that belongs to no framework. That single description is the asset. From it, the tool generates the outputs an agent or a client needs: today an MCP server (the open protocol agents use to call tools) and an OpenAPI document.
Because both come from the same description, they cannot disagree, and rebuilding regenerates them from whatever your source now says. The same input always produces the same output.
Structure decides, or nothing does.
Exposed
A read is exposed when a framework contract proves it. A standard repository load by primary key is a load by primary key by contract, not because a method happens to be named getById.
Refused, ambiguous
When two methods both fit the shape of the read, the tool refuses rather than pick one. A real example: an entity with both findById and findByUsername is refused, not guessed.
Refused, unprovable
When meaning is not in the structure, it is refused. A check sitting between the load and the return could be an authorization rule; the tool cannot tell, so it will not claim.
Method names, parameter names, and comments carry no weight anywhere in this. They are the easiest thing to get wrong, and a tool an agent trusts cannot lean on them.
A structural tool tops out at what structure can prove, and says so.
Today that means unfiltered reads by id and unfiltered lists. The filtered majority of a real application's read API, the searches and the category lookups, is beyond structural proof: a filter's meaning is a claim, and a claim in a tool description is something an agent acts on. So the tool refuses it rather than present a guess as verified.
Where that boundary can move honestly, it is designed and waiting. A human can attest to a capability the structure cannot prove, and it would be carried as exactly that, human attested, never as verified. That work is built when a real adopter hits the boundary, not before.
Adoption is a dependency and a build step. Nothing is hosted by us.
You add one runtime dependency and one build plugin to your application. Your own build generates the tool manifest from your source and places it on the classpath. The server runs inside your application's own process and calls your real methods. There is no Tibyaan service in the path at runtime, nothing metered, no vendor infrastructure.
Remove the two build-file entries and the layer is gone. You never touched your original code.
The full design, all seventeen volumes and the dated benchmark ledgers, lives in the repository (opens in a new tab).