MCP
What an application exposes to a MCP client, and how. Everything here lives in io.yupiik.fusion.mcp.api: two build time markers plus two runtime SPIs.
| Page | Exposes | Through |
|---|---|---|
|
what the model can call |
|
|
|
templates the user picks, and their argument completion |
|
|
|
data the client can read and attach |
the |
|
|
logging, notifications, sampling, elicitation, roots |
|
Choosing the right one
| Need | Use |
|---|---|
|
The model should be able to act or look something up |
a tool |
|
The user should be able to trigger a prepared instruction |
a prompt |
|
The client should be able to read data and attach it to the conversation |
a resource |
|
The server needs to tell the client something happened |
|
|
The server needs the client model, its user or its workspace |
|
TIP
|
tools and prompts are code, known at build time, hence the annotations; resources are data, discovered at runtime, hence the SPI. See Design for the reasoning. |
Common ground
-
every extension point is a plain Fusion bean or method: constructor injection, scopes and
@Orderall work as usual, -
nothing is reflective: the descriptors and the JSON codecs are generated at build time,
-
a method can be asynchronous (
CompletionStage<T>) and can take aio.yupiik.fusion.http.server.api.Requestparameter to reach the MCP session, -
what a client is told the server can do - its capabilities - is computed from what is actually deployed, so an empty extension point is never advertised.