
oopsyz/mcp
Developer toolsЭта страница переведена автоматически. Технические детали смотрите в оригинале. Открыть оригинал
This repo exposes the TMF620 command layer through two interfaces:
Обзор
This repo exposes the TMF620 command layer through two interfaces:
README
Показан фрагмент оригинального README. Открыть оригинал.
TMF620 CLI vs MCP
This repo exposes the TMF620 command layer through two interfaces:
- a compact HTTP CLI API for progressive discovery
- an MCP server used here as a reference surface for benchmarking and testing
Documentation index: docs/README.md
The engine-specific oa-engine CLI-over-HTTP control-plane profile
is maintained in the oa_engine repository; this repository owns the generic
CLI-style HTTP protocol.
Repository layout:
tmf620/- TMF620 mock API, shared client, commands, server, and benchmarktests/- pytest-discoverable wrappers plus standalone conformance, API, and edge-case scriptsdocs/- long-form protocol docs and guidesbenchmarks/- benchmark scripts and baseline datascripts/- repo entrypoint scriptsspecs/- source OpenAPI and protocol specstmf620/config/- TMF620 runtime configuration filesDOMAIN.md/AGENTS.md- repo-level contracts and agent instructionstmf620/config/config.json- canonical runtime data and configuration
The TMF620 sample implementation is kept in a service-local folder so it can be deployed independently of other systems.
The CLI API is the cheaper discovery path for agents that only need one command branch at a time. The MCP server is retained here as a comparison point for discovery payloads, tool-list size, and latency measurements.
The practical reasons to keep both are:
- compact discovery: agents can start with
GET /cli/tmf620/catalogmgtinstead of ingesting the full MCP tool list up front - progressive help: agents can expand one command branch at a time with
help - stronger MCP contracts: MCP tools now expose explicit schemas instead of a generic
argsobject - simpler automation:
curlworks well for both humans and agents, especially when the command surface is already structured - one shared command layer: the same command definitions back the HTTP CLI API, the MCP reference surface, and the benchmark
TMF620 Product Catalog Management with three layers:
- a mock TMF620 API
- a shared Python client
- two adapters over that client: HTTP CLI API and MCP
This keeps the operational logic in one place while supporting HTTP and MCP adapters over the same TMF620 command set.
Request paths:
- HTTP CLI API ->
tmf620/server.py->tmf620/commands.py->tmf620/core.py-> TMF620 API - MCP client ->
tmf620/server.py->tmf620/core.py-> TMF620 API
Components
1. Mock TMF620 API
File: tmf620/mock_api.py
- FastAPI-based TMF620 mock server
- sample catalogs, offerings, and specifications
- Swagger docs
2. Shared TMF620 Client
File: tmf620/core.py
- config loading
- HTTP request handling
- health checks
- generic CRUD helpers for TMF620 resources
- catalog, category, offering, price, specification, import/export job, and hub operations
3. Shared Command Layer
File: tmf620/commands.py
Установка
This server does not publish a one-line install command.
Open the repository installation guide Новичок в MCP? Начните с руководства на mcpskill.org →Конфигурация
{
"mcpServers": {
"tmf620-mcp": {
"command": "uv",
"args": ["run", "tmf620-mcp-server"],
"cwd": "/path/to/tmf620-mcp-server"
}
}
}