Click on "Deploy 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., "@mcp-server-senseca-pro What is the current temperature?"
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.
An MCP server that lets AI assistants read live measurements from a Senseca PRO 111 / PRO 115 handheld Pt100 thermometer connected via USB.
Unofficial project, not affiliated with or endorsed by Senseca. Tested with a PRO 111, firmware V1.4.3.0, interface protocol V1.0.0.1.
Tool | Description |
| Current temperature with unit (°C/°F/K, as set on the instrument) and UTC timestamp |
| Current Pt100 resistance in ohm |
| Readings over a period (max 600 s, interval ≥ 0.5 s) with min/max/mean/stdev |
| Model, serial number, firmware, instrument clock, battery level |
With --allow-write two more tools are available:
Tool | Description |
| Set the instrument clock (default: this computer's time) |
| Rename one of the 20 location labels |
The server cannot change calibration or adjustment data; the instrument does not offer that over its serial interface.
Related MCP server: @inscada/mcp-server
Python ≥ 3.10 and uv
The instrument switched on and connected via USB-C. On the PRO 115 set Settings → USB mode to COM interface.
Linux: your user must be in the dialout group (sudo usermod -aG dialout $USER, then log in again).
Windows / macOS: no extra setup; the port shows up as COMx or /dev/cu.usbmodem….
claude mcp add senseca-pro -- uvx mcp-server-senseca-pro{
"mcpServers": {
"senseca-pro": {
"command": "uvx",
"args": ["mcp-server-senseca-pro"]
}
}
}Option | Environment variable | Default |
|
| auto-detect |
|
| off |
|
|
|
— |
| none; needed only if the instrument's protected mode is on |
Auto-detection looks for USB ID 0483:5740 and only accepts a port whose device reports
manufacturer senseca. If several instruments are connected, set the port explicitly; on Linux
prefer the stable /dev/serial/by-id/… path.
Only one program can use the serial port at a time. Close ProXware or terminal programs while the server is running.
Instrument accuracy: ±0.05 °C or ±0.06 % of reading (whichever is higher) ±1 digit, probe not included.
The USB port is not galvanically isolated. With a probe touching a grounded medium, the USB connection can shift the reading. Compare readings with and without USB, and use a USB isolator if they differ (see the instrument manual, section 7.2).
uv sync
uv run pytest # tests use a simulated instrument
npx @modelcontextprotocol/inspector uv run mcp-server-senseca-pro # try the tools interactivelyTo check a real instrument, connect it and run:
uv run python scripts/hardware_test.py # read-only checks, no interaction
uv run python scripts/hardware_test.py --reconnect # also unplug/replug USB when askedThe script only sends read commands. See --help for the PIN test.
The serial protocol is described in docs/protocol.md.
MIT
Instrument model, serial number, firmware, clock (UTC) and battery level.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds minor value by naming the clock as UTC, but that is return-content detail rather than behavioral context, and an output schema already exists to carry it.
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?
It is short and free of waste, but it is a sentence fragment with no leading verb, so the most important information (what the tool does) is never front-loaded. Listing fields first inverts the natural order.
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?
Return values are covered by the existing output schema and annotations cover the safety profile, so little is strictly required. Still, a zero-parameter metadata tool should state in one clause that it returns the connected instrument's identity/status rather than just enumerating fields.
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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly doesn't invent parameters.
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 is a noun-phrase list of fields ('Instrument model, serial number, firmware, clock (UTC) and battery level') with no verb, so it never states that the tool retrieves device information. The field list does imply the resource and distinguishes it from the temperature/resistance siblings, but the action is only inferable from the tool name.
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 guidance on when to call this versus read_temperature, read_resistance, or sample_temperature, and no prerequisites or conditions stated. The agent must infer from the tool name that this is the device-metadata path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the current Pt100 probe resistance in ohm (about 100 ohm at 0 °C).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context — the unit and the ~100 ohm at 0 °C baseline, which lets an agent sanity-check for an open/faulty probe — but says nothing about fault readings or measurement timing.
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?
A single front-loaded sentence with the resource and units up front and the expected-value cue in parentheses. Nothing is wasted and nothing essential is buried.
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?
An output schema exists, so return values need no explanation, and annotations cover the safety profile for this zero-parameter read. The only real gap is edge-case behavior (e.g., what a fault or out-of-range ohm value means).
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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The parenthetical about 100 ohm at 0 °C is a helpful interpretive note rather than parameter semantics.
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?
Specific verb (read) plus a precise resource (Pt100 probe resistance) with units stated, which cleanly separates it from read_temperature and sample_temperature by measurand. It stops short of explicitly naming the siblings it differs from, so an agent must infer the distinction from the resource name.
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 statement of when to choose this over read_temperature or sample_temperature (continuous sampling?), and no preconditions or exclusions. The description gives interpretation context but no selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the current temperature from the Pt100 probe, with unit and UTC timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond them: the reading comes from a specific Pt100 probe and returns a unit plus a UTC timestamp, telling the agent how to interpret the value. It does not mention error behavior when the probe is absent, keeping it below a 5.
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?
A single front-loaded sentence with zero filler; the sensor, the value, and the returned metadata are all stated compactly.
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?
With an output schema present and annotations covering safety, the description only needs to frame the operation, which it does. The remaining gap is that it never positions itself relative to the closely named sibling 'sample_temperature'.
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 tool takes zero parameters, so there is no per-parameter semantics to explain; the baseline for a 0-param tool applies. The description correctly implies no input is needed.
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?
States a specific verb and resource ('Read the current temperature from the Pt100 probe') plus the returned fields (unit, UTC timestamp). It does not differentiate itself from the sibling 'sample_temperature', so an agent must infer whether it is a single read vs. a sampling routine.
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 word 'current' implies a single instantaneous reading, which hints at when to use it, but there is no explicit guidance about when to prefer it over 'sample_temperature' or 'read_resistance', and no prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record temperature readings over a period and return statistics plus all samples.
Args: duration_s: Recording time in seconds (max 600). interval_s: Time between readings in seconds (min 0.5, the instrument's update rate).
| Name | Required | Description | Default |
|---|---|---|---|
| duration_s | No | ||
| interval_s | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds valuable context beyond that: a 600s maximum recording window, a 0.5s minimum interval tied to the instrument's physical update rate, and the fact that both aggregate statistics and raw samples are returned. It does not mention whether the call blocks for the full duration or how long 600s of sampling behaves, which keeps it at a 4.
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 behavioural summary is front-loaded in one sentence and the two parameters follow in a compact arg list, with no wasted prose. The 'Args:' block is conventional rather than elegant, but every line carries non-redundant constraint information.
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?
With an output schema present, the description needn't enumerate return fields, and its one-line summary of 'statistics plus all samples' is sufficient signposting. Annotations cover safety and idempotency, and the binding constraints on both parameters are supplied, leaving only edge-case behaviour (blocking, truncation, error conditions) unaddressed.
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 description coverage is 0%, so the description must carry the parameter semantics, and it does: it documents units (seconds), a hard maximum of 600 for duration_s, a minimum of 0.5 for interval_s, and explains interval_s as the instrument's update rate rather than an arbitrary knob. Defaults and types are left to the schema, so it is not exhaustive.
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 states a specific verb and resource ('Record temperature readings over a period') plus the output shape ('return statistics plus all samples'), so the agent knows exactly what the tool does. It does not explicitly contrast itself with the sibling read_temperature, which is likely a single instantaneous read, so it falls short of a 5.
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?
Usage is only implied: 'over a period' suggests this is the time-series/multi-sample option, which an agent can infer as distinct from read_temperature. There is no explicit 'use this when...' or exclusion statement naming read_temperature as the alternative for one-off reads.
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.
v0.1.1get_device_inforead_resistanceread_temperaturesample_temperatureScored across 4 tools
Each tool has a clearly distinct role: two single-value reads for different physical quantities (temperature vs. resistance), one time-series sampling tool, and one device metadata tool. The boundary between read_temperature and sample_temperature is clear because one is a spot reading and the other records over time.
All names follow a consistent snake_case verb_noun pattern: read_temperature, read_resistance, sample_temperature, get_device_info. The verbs are predictable and match the operation type.
Four tools are well-scoped for a Pt100 sensor server with a small, focused read-only domain. Each tool earns its place without redundant operations.
The surface covers current temperature, raw resistance, time-series sampling with statistics, and device metadata, which covers the core monitoring workflow. Minor gaps such as calibration or configuration operations are reasonable for a read-only instrument server but prevent a perfect score.
Your own SLATE health data in your AI assistant: read, trend, plan and log. Never suggests a dose.
Connects AI assistants to TrackingTime for querying time entries, projects, tasks, customers, and team data using natural language.
Home energy for AI assistants: live Power flow, Energy history, solar forecast, and device control.
Read pet activity and weight history, and log events with your permission.
