Skip to main content
Glama
Sign In
SensorForge MCP Server

SensorForge MCP Server

by sidupreti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Check data locally

check_data
Read-only

Validate a local .npz or image-zip dataset against your model's input shapes and classes before optimization. Explains each problem and how to fix it, with no upload or run used.

Instructions

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.

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>"
    },
    "name": "check_data"
  }
}

Input Schema

NameRequiredDescriptionDefault
outputNo'classes' when the model outputs class scores; 'values' for detectors, autoencoders and regression.classes
data_pathYesThe data: an .npz (X, y) or a .zip of image folders, one per class.
model_pathYesThe model the data is for (.tflite, .onnx, or a firmware .zip).

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 establish that the tool is read-only, non-destructive, and not open-world. The description adds useful behavioral context beyond those hints: it performs local validation, uploads nothing, uses no run, and explains each problem with a fix. It does not describe the success output or exact return format, but the behavioral additions are substantive.

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?

The description is front-loaded with the core action and then organized by data format. Despite dense technical detail, every sentence contributes to telling the agent what is validated and what the side effects are.

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?

For a local read-only validation tool with full schema coverage and safety annotations, the description covers the key inputs, validation expectations, and side-effect guarantees. Its main minor gap is that it does not describe what a successful check returns, but it does state that problems are explained along with fixes.

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 model_path, data_path, and the output enum. The description elaborates on expected data contents, such as X being float32 and y being one class index per sample, but most of this is validation behavior rather than additional parameter semantics beyond the schema.

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?

The description uses a specific verb and resource: "Check, locally, that a data file is what optimize needs for this model." It further distinguishes itself from the optimize workflow by saying this happens "before uploading anything" and that "no run is used." The format-specific validation details make the tool's purpose unambiguous.

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?

The description clearly states when to use it: before uploading data for optimize, to verify the data matches the model's needs. It gives no explicit exclusions or named alternatives, such as check_fit, but the context is clear enough for an agent to choose it appropriately.

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