docs: define multi-tool scaffold design
This commit is contained in:
@@ -0,0 +1,77 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user