78 lines
2.7 KiB
Markdown
78 lines
2.7 KiB
Markdown
# Multi-tool Scaffold Design
|
|
|
|
## Goal
|
|
|
|
Extend the Tool Scaffold so one UseCase can expose multiple MCP Tools, and each
|
|
Tool can call its own typed integration Client using the same flow as
|
|
`CustomerGuidanceToolUseCaseImpl`.
|
|
|
|
## Generated structure
|
|
|
|
For a Scaffold group named `Customer`, the generator creates one UseCase and
|
|
implementation, with one method per Tool:
|
|
|
|
```java
|
|
public interface CustomerUseCase {
|
|
@McpTool(name = "cmm_customer_guidance", ...)
|
|
CustomerGuidanceResponse searchGuidance(CustomerGuidanceRequest request);
|
|
|
|
@McpTool(name = "cmm_customer_contract", ...)
|
|
CustomerContractResponse searchContract(CustomerContractRequest request);
|
|
}
|
|
```
|
|
|
|
Each Tool has independent metadata:
|
|
|
|
- MCP Tool name, title, description, category and registration flag
|
|
- Java method name
|
|
- integration interface ID
|
|
- Client class and Client method name
|
|
- request and response fields
|
|
- generated V17 Tool definition YAML
|
|
|
|
The implementation follows the CustomerGuidance pattern per method:
|
|
|
|
```text
|
|
Tool Request -> MapStruct Converter -> Typed *Client -> MapStruct Converter -> Tool Response
|
|
```
|
|
|
|
For MCI, the generator creates a typed Client method such as
|
|
`callOnild0320(ONILD0320_I)` rather than having the UseCase call generic
|
|
`callTo(...)` directly. The Client remains the only layer that calls
|
|
`AxhubMciComponent`.
|
|
|
|
## Field model
|
|
|
|
Existing scalar types remain supported: `String`, `Integer`, `Long`, `Double`,
|
|
`Boolean`, and `BigDecimal`.
|
|
|
|
Two structured choices are added:
|
|
|
|
1. **Enum**: the user supplies allowed values. The generator creates a named
|
|
enum class beside the DTO, uses it as the field type, and emits the same
|
|
values in the MCP parameter schema.
|
|
2. **List**: the user selects an item kind.
|
|
- Primitive lists generate e.g. `List<String>`.
|
|
- Object lists contain user-entered item fields and generate a separate
|
|
`...Item` DTO plus `List<...Item>`.
|
|
|
|
The Scaffold UI presents enum values and list item fields in dedicated dialogs,
|
|
instead of asking the user to hand-author Java or JSON type expressions.
|
|
|
|
## Compatibility
|
|
|
|
- The existing one-Tool request payload continues to work and generates the
|
|
current single-Tool shape.
|
|
- The new multi-Tool payload is additive and is used by the updated UI.
|
|
- Existing generated source is not rewritten.
|
|
- Each generated Tool continues to receive its own V17 YAML file, which keeps
|
|
runtime tool discovery and validation unchanged.
|
|
|
|
## Validation and tests
|
|
|
|
- Validate unique Tool names and Java method names within a UseCase group.
|
|
- Validate a Client class/method and interface ID for each MCI Tool.
|
|
- Validate enum values and object-list item fields.
|
|
- Add generator tests for multiple methods, typed MCI Client calls, enum DTOs,
|
|
primitive lists, object lists, and V17 schema output.
|