49 lines
1.1 KiB
Markdown
49 lines
1.1 KiB
Markdown
# MCP Strategy (Draft)
|
|
|
|
## Objective
|
|
|
|
Expose read-only accounting data to assistant tools through MCP while preserving integration safety.
|
|
|
|
## Variant A: OData -> MCP Bridge
|
|
|
|
Use external OData-to-MCP proxy first for fast validation:
|
|
|
|
- Candidate: `oisee/odata_mcp_go`
|
|
- Candidate: `lemaiwo/odata-mcp-proxy`
|
|
- Input: 1C OData endpoint + read-only credentials
|
|
- Output: MCP tools generated from metadata
|
|
|
|
### Pros
|
|
|
|
- Fastest prototype path
|
|
- Low custom code for initial tool exposure
|
|
|
|
### Cons
|
|
|
|
- Tool surface can be too broad
|
|
- Requires strict read-only guardrails
|
|
|
|
## Variant B: Canonical API -> Custom MCP
|
|
|
|
Build MCP on top of `canonical_layer` API endpoints:
|
|
|
|
- Source is normalized entities
|
|
- Tools are curated by scenario, not by raw OData entity set
|
|
|
|
### Pros
|
|
|
|
- Better assistant UX and stable semantics
|
|
- Easier security and observability control
|
|
|
|
### Cons
|
|
|
|
- More engineering work
|
|
|
|
## Recommended Sequence
|
|
|
|
1. Validate data depth with OData probe.
|
|
2. Ship API scenarios in canonical layer.
|
|
3. Start MCP with bridge for speed.
|
|
4. Migrate to custom MCP on canonical API if bridge is noisy or limited.
|
|
|