SensorForge MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SENSORFORGE_LOG | No | Log level on stderr. | WARNING |
| SENSORFORGE_URL | No | The SensorForge service URL. | https://sensorforge.dev/optimize |
| SENSORFORGE_API_KEY | Yes | Your SensorForge API key (required). Keys start with sfk_. | |
| SENSORFORGE_MCP_HOME | No | Where the local run list is kept. | ~/.sensorforge-mcp |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
SensorForge Optimizer: we shrink trained models to fit edge devices. Upload a .tflite or .onnx model; get back a TensorFlow Lite Micro model (and its C sources) that needs less SRAM and flash, within the accuracy limit you set. Every figure is measured by running the file.
Typical flow: list_chips -> check_fit (seconds) -> lossless (under a minute, no data, outputs identical) -> check_data (local) -> optimize (5-60 minutes, needs data) -> wait_for_run (call again while it says still running) -> download. Paths may be relative to the working directory or start with ~. Needs SENSORFORGE_API_KEY.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_chipsA | List the chips (edge devices) the optimizer targets, with each one's SRAM and flash budget for the model.
Use a chip's name as |
| check_fitA | Check whether a model runs on one or more chips and how much SRAM and flash it needs there, measured. Takes seconds; no data needed. Returns a per-chip verdict with SRAM and flash against each chip's budget, and the SRAM lossless would reach. Use it first, before lossless or optimize. |
| check_dataA | Check, locally, that a data file is what optimize needs for this model, before uploading anything. For an .npz: X present, float32, each sample in the model's input shape; y one class index per sample within the model's outputs; X_test / y_test if given. For an image zip: class folders (or train/ and test/). Explains each problem and how to fix it. Nothing is uploaded and no run is used. |
| losslessA | Make the model smaller in SRAM and flash with outputs bit-identical to the original: no data, no retraining. Usually under a minute. Waits for the result, downloads it, and unpacks the model for TensorFlow Lite Micro and its C sources into the project. Returns the before -> after figures and the files. If it is still running after about four minutes it returns the run id: then call wait_for_run and download. |
| optimizeA | Find the smallest model for the chip within your accuracy limit, retrained on your data. Runs on the service for 5-60 minutes, so this returns right away with the run id and its place in the queue: then call wait_for_run(run_id) (again while it says still running), and download(run_id) when it passes. The data is used for this run only and deleted when it ends. |
| run_statusA | The state of a run right now, without waiting: queued (with its place in line), running (with its latest progress), or finished with the verdict and the before -> after SRAM, flash and accuracy. |
| wait_for_runA | Wait for a run to finish, checking about every 10 seconds and reporting progress. Returns the final result (verdict and before -> after figures), or 'still running, call again' when max_wait_s is up: then call wait_for_run again. Optimize runs take 5-60 minutes, so expect several calls. |
| get_reportA | The run's full report as markdown: the measured figures, what was changed and why, and what to do next. Available on every plan, including the trial. |
| downloadA | Download a finished run's result and unpack it into the project: the model for TensorFlow Lite Micro, its C sources (c/: the model as a C array, the operator list, integration notes) and the report. Refuses to write into a folder that is not empty unless overwrite=True. Returns each file and what it is for. |
| list_runsA | The account's recent runs, newest first: id, when, kind, model, status and verdict. Runs are kept 14 days. |
| stop_runA | Stop a queued or running run, for example one sent with the wrong chip or data. A stopped run gives no result; submit it again to rerun. |
| accountA | The account's plan, this month's usage, and how many runs are left today (with when the next one is free when a daily cap is reached). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| fit_model_to_chip | Walk through fitting a trained model to an edge device: check fit, lossless, check the data, optimize, wait, download. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
The core workflow tools are well separated: check_data validates locally, check_fit measures fit without data, lossless shrinks without data, and optimize retrains on data, with descriptions stating the ordering. The main soft spot is the run-inspection cluster (list_runs, run_status, wait_for_run, get_report) plus download, which overlaps with lossless since lossless also downloads and unpacks output — but each still has a stated distinct behavior.
Most tools follow snake_case verb_noun (list_runs, stop_run, check_fit, check_data, run_status, wait_for_run, get_report), but a large minority are bare single words of mixed grammatical type: download, optimize (verbs), account (noun), lossless (adjective). Readable, but the convention is not predictable across the set.
Twelve tools map cleanly onto a coherent pipeline (inspect chips, validate data, check fit, optimize/lossless, poll, download, report, account, stop) with no filler or duplicate endpoints. Well within the well-scoped 3–15 range.
The run lifecycle is covered end to end: discovery (list_chips), preflight (check_data, check_fit), execution (optimize, lossless), progress (run_status, wait_for_run), cancellation (stop_run), output retrieval (download, get_report), plus history and quota (list_runs, account). Minor gaps remain, such as deleting/cleaning up old runs or a plain fetch of results without unpacking into a project directory.