Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@KETI FLOW MCP what is the optimal blower angle for a flow of 500?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
송풍기/펌프 운전점 데이터를 서버 시작 시마다 학습하고, 에이전트가 MCP tool로 최적 제어값을 조회할 수 있게 하는 독립 MCP 서버입니다.
KETI_FLOW_MCP/
├─ src/
│ ├─ train/
│ ├─ mcp_server/
│ └─ utils/
├─ data/
├─ tests/
├─ config/
│ └─ config.json
├─ main.py
├─ pyproject.toml
├─ uv.lock
├─ README.md
└─ .gitignoresrc/mcp/는 Python MCP SDK의 mcp 패키지명과 충돌할 수 있어 사용하지 않습니다.
Related MCP server: ML MCP Server
cd C:\Users\keti\workspace\KETI_FLOW_MCP
uv sync가상환경은 .venv/에 생성됩니다.
학습 데이터는 data/ 아래에 둡니다. 이 폴더는 기밀 데이터 위치이므로 git에서 추적하지 않습니다.
기본 설정은 다음 파일을 사용합니다.
data/blower/fan_training.csv
data/pump/pump_training.csv기본 CSV 컬럼은 다음과 같습니다.
Flowrate,Head,Power,Angle,Speed현재 MCP tool은 요구 유량 Flowrate를 입력받아 Power가 최소가 되는 Angle 값을 찾습니다.
설정 파일은 config/config.json입니다.
주요 항목:
data.base_dir: 학습 데이터 기준 폴더
machines.<name>.data_file: 장비별 CSV 경로
flow_column: 유량 컬럼
control_column: 최적화할 제어값 컬럼
target_column: 최소화 또는 최대화할 목표 컬럼
optimization: minimize 또는 maximize
candidate_count: 실시간 탐색 후보 개수
respect_control_flow_range: 제어값별 학습 유량 범위를 엄격히 적용할지 여부
uv run python main.py서버는 실행 시 다음 순서로 동작합니다.
config/config.json 로딩
data/의 CSV 로딩
송풍기/펌프 모델 메모리 학습
MCP stdio 서버 시작
모델 파일과 LUT 파일은 생성하지 않습니다.
get_optimal_blower_angle입력:
{
"required_flow": 500.0
}응답 예:
해당 유량에서 적절한 각도 제어 값은 49 입니다. 예측 Power: 2.739 kW범위 밖 응답 예:
해당 유량은 학습 데이터 범위 내 값이 아닙니다. 지원 범위: 500 ~ 900get_optimal_pump_control입력:
{
"required_flow": 5.0
}keti-flow://training-status현재 서버 프로세스에 학습된 모델 상태, 데이터 파일, 행 수, 유량 범위를 반환합니다.
Codex MCP 설정에서 다음 형태로 등록합니다.
{
"mcpServers": {
"keti-flow": {
"command": "uv",
"args": [
"--directory",
"C:\\Users\\keti\\workspace\\KETI_FLOW_MCP",
"run",
"python",
"main.py"
]
}
}
}Claude Desktop 설정 파일의 mcpServers에 다음 항목을 추가합니다.
{
"mcpServers": {
"keti-flow": {
"command": "uv",
"args": [
"--directory",
"C:\\Users\\keti\\workspace\\KETI_FLOW_MCP",
"run",
"python",
"main.py"
]
}
}
}tests/는 로컬 검증용 폴더이며 git에서 추적하지 않습니다.
간단한 smoke 검증:
uv run python -c "from src.mcp_server.server import build_runtime; r=build_runtime(); print(r.status())"송풍기 예측 확인:
uv run python -c "from src.mcp_server.server import build_runtime, optimal_control_text; r=build_runtime(); print(optimal_control_text(r, 'blower', 500))"다음 항목은 git에 포함하지 않습니다.
data/
tests/
.venv/
모델 산출물 파일
로그와 로컬 출력물
이 도구는 송풍기의 날개 각도를 최적 제어하는 도구로서, 사용자가 송풍기의 유량을 입력하며 운전점을 알고 싶다고 하면 해당 도구를 호출하여 최적 운전점을 도출함.
| Name | Required | Description | Default |
|---|---|---|---|
| required_flow | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions 'controlling' and 'deriving optimal operating point', but it is unclear whether this tool actually actuates the blower or just computes. It lacks information on side effects, permissions, or safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The two-sentence description is reasonably concise and front-loaded with the purpose. However, it contains some redundancy and could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema exists but is not described in the text, the description does not explain the return value or the nature of the 'optimal operating point'. It also fails to clarify whether this tool is purely computational or performs a control action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the sole parameter 'required_flow' by stating it is the flow rate of the blower. However, it does not specify units or acceptable ranges. With 0% schema coverage, the description provides essential context but is not fully comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it controls the blower blade angle optimally based on required flow. The sibling tool 'get_optimal_pump_control' is for pumps, providing implicit differentiation, but the description does not explicitly distinguish them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage context: call when user inputs flow rate and wants the optimal operating point. However, it does not specify when not to use this tool or mention alternatives, such as the pump control tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
이 도구는 펌프의 VIGV를 최적 제어하는 도구로서, 사용자가 펌프의 유량을 입력하며 운전점을 알고 싶다고 하면 해당 도구를 호출하여 최적 운전점을 도출함.
| Name | Required | Description | Default |
|---|---|---|---|
| required_flow | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose side effects (e.g., whether pump settings are changed), permissions, or safety considerations. Behavioral traits are inadequately conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is relatively concise with two clauses, but could be more structured and front-loaded. Some repetition ('pump', 'operating point'). Adequate but not optimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description doesn't mention return values. Missing operational context like when to call, prerequisites, or expected outcomes. Incomplete for a tool with a sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description adds that user inputs flow rate but lacks units, range, or format details. Insufficient compensation for schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's purpose: optimally controlling pump VIGV and deriving optimal operating point based on user input flow. Distinguishes from sibling tool for blower angle implicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives. Only mentions 'if user wants to know operating point'. No comparison with sibling tool or conditions for avoidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_optimal_blower_angleget_optimal_pump_controlThe two tools address completely different physical devices (blower vs. pump), so there is no ambiguity in their purposes. Each has a clear and distinct function.
Both tools follow the same pattern of 'get_optimal_<device>_<control/angle>', using consistent verb_noun structure and snake_case. The minor difference in the last word (angle vs control) does not break consistency.
With only 2 tools, the server is very narrowly scoped. While this may be acceptable for a focused use case, it feels minimal for a general flow control system, suggesting the surface is thin.
The tools cover only optimization for two specific devices. There are no tools for monitoring current state, setting parameters, or managing other equipment, leaving significant operational gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Cross-OEM industrial machine intelligence: identity, normalization, automation, attestation.
Protocol-native energy infrastructure orchestration for AI data centers. Provides 46 MCP tools across 8 grid protocols (IEC-61850, DNP3, Modbus, OCPP, OpenADR, IEEE 2030.5, IEC 60870-5-104, ICCP) with 5 core API primitives: connect, dispatch, settle, comply, and intel. Enables AI agents to programmatically interact with substations, grid interfaces, and energy assets for real-time workload-grid coordination.
Real-time electricity price signals for AI agents. Spot prices, cheapest hours, and contract recommendations. 31 countries across Europe and Oceania. No authentication required.
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/CodeNinja1126/KETI_FLOW_MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
