stoneai MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PYTHONUTF8 | No | Set to 1 to enable UTF-8 mode for Python, avoiding garbled Chinese paths / output. | |
| STONEAI_CLI | No | Path to SToneCLI.exe. Defaults to the standard CAREL STone installation path if not set. | |
| PYTHONIOENCODING | No | Set to utf-8 so that Chinese paths / Chinese output are not garbled. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| stone_doctorA | Check the STone environment: SToneCLI, IronPython API and whether a dummy solution compiles (valid license). |
| stone_solution_createC | Create a new STone solution from a template (BaseProject, EmptyProject, ...). Returns the solution path. |
| stone_solution_stateC | List projects, registered files and build configurations of a .stone solution. |
| stone_files_addB | Write an .st source into a project, register it and compile. Returns build diagnostics (code, file, line, column). |
| stone_buildB | Compile a solution/project. Returns structured errors and warnings and the flash.bin artifact path when it succeeds. |
| stone_symbolsC | Symbol index of the last build: POUs, their member interfaces (inputs/outputs/locals with types), variables, tasks, types. Optional: query=substring, interfaces=true. |
| stone_api_searchC | Search the CAREL System.* library API (1000+ entries) for functions and function blocks, e.g. keyword 'log', 'alarm', 'modbus'. |
| stone_snippetC | Show the IDE's own ST code snippets (exact statement spellings). |
| stone_pou_generateC | Generate a compiling PROGRAM/FUNCTION_BLOCK skeleton with typed variable sections; the body stays yours. |
| stone_target_connectC | Connect STone to a target, e.g. 'TcpIp,10.10.9.128,4122'. |
| stone_watch_readC | Read one variable from the connected target. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
Most tools target distinct resources/actions (doctor, create, state, build, symbols, connect, read). There is mild overlap: stone_files_add both writes a file and compiles while stone_build compiles, and stone_pou_generate also produces ST source; similarly stone_api_search vs stone_snippet are both reference lookups. Descriptions clarify the boundaries adequately.
All tools share a 'stone_' snake_case prefix, making them clearly cohesive. However, the suffix pattern mixes noun-only labels (stone_doctor, stone_build, stone_symbols, stone_snippet) with verb_noun forms (stone_solution_create, stone_target_connect, stone_watch_read), a minor deviation.
Eleven tools is well within the ideal 3-15 range. Each tool maps to a distinct step in the STone workflow (setup, create, build, inspect, generate, connect, monitor) and none feel redundant.
Core lifecycle is present (create solution, add files, build, inspect symbols, connect, read). But notable gaps exist: only stone_watch_read with no variable write, no target disconnect, and no file/project delete or update operations, which limits full PLC round-trip workflows.