Skip to main content
Glama
Sign In
SensorForge MCP Server

SensorForge MCP Server

by sidupreti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Optimize within an accuracy limit

optimize

Shrink and retrain a model to fit a target chip's memory limits within your accuracy tolerance, using your own data.

Instructions

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "model_path": "<model_path>",
      "data_path": "<data_path>",
      "chip": "<chip>"
    },
    "name": "optimize"
  }
}

Input Schema

NameRequiredDescriptionDefault
chipYesA chip name from list_chips.
effortNo'quick' (about 15 minutes) or 'thorough' (up to an hour; not on the trial).quick
outputNo'classes' for class scores; 'values' for detectors, autoencoders and regression (y not needed).classes
ram_kbNoSRAM budget in KB (default: the chip's).
flash_kbNoFlash budget in KB (default: the chip's).
minimizeNoWhat to shrink: SRAM ('ram'), flash, or both.ram
data_pathYesThe data: an .npz (X, y) or a .zip of image folders, one per class. Run check_data first.
model_pathYesThe trained model: .tflite or .onnx, or a .zip of a firmware export.
check_firstNoRun the local data check first and stop on problems.
image_scalingNoImage zips only: how the model expects pixels. 'auto' = as the model says (int8 .tflite files carry it).auto
accuracy_limitNoHow many points of accuracy the result may lose against your model, on the test part of the data.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare it is not read-only, not idempotent, not destructive, and open-world, but the description adds what the annotations cannot: this is an asynchronous long-running job that returns immediately with a run id plus queue position, and a failure mode ('when it passes'). It also discloses the data lifecycle (used for this run only, deleted when it ends), which matters for a tool uploading user data. It does not mention credit/cost consumption or what happens to the produced artifacts.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose in one clause, then the asynchronous workflow, then the data-retention note — three short sentences with no filler. Every clause carries information an agent needs (timing, queue, follow-up calls, data deletion).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 11 parameters, no output schema, and a multi-step async workflow, the description rightly compensates by explaining the return (run id and queue place) and the exact follow-up calls. What remains thin is guidance on the trade-offs among effort/minimize/budget parameters, which the schema covers only factually.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 11 parameters, including accuracy_limit, effort, minimize, and the ram/flash budgets. The description only indirectly echoes accuracy_limit ('within your accuracy limit') and data_path ('retrained on your data'); it adds no syntax, defaults, or trade-off guidance beyond the schema. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and outcome: find the smallest model for the chip within an accuracy limit, retrained on the user's data. It distinguishes itself from the surrounding run/check tools by describing an optimization search over model size under an accuracy constraint, and it names the siblings it hands off to (wait_for_run, download).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear operating context: long server-side job (5-60 min), returned run id, then poll wait_for_run repeatedly while still running, then download when it passes. It does not say when NOT to use it — e.g. versus lossless or check_fit — nor that a data check should precede it (only the schema hints at that).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools