Read all configured sensors on an ESP32 board, including chip temperature and analog channels, returning raw ADC counts, millivolts, and scaled values for local monitoring.
Read every sensor configured in the firmware: the internal chip temperature and each analog channel, with raw ADC counts, millivolts and a scaled value.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Read' makes the non-mutating nature clear and the sentence usefully discloses the shape of the returned readings (raw counts, mV, scaled), but says nothing about behavior when no sensors are configured, error responses, or sampling 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 well-formed sentence that front-loads the verb and scope, then lists the outputs. No filler, nothing repeated from the schema.
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?
For a zero-parameter read tool with no annotations and no output schema, the description covers what the call does and what comes back, which is most of what an agent needs. It falls short only on edge cases like an empty sensor configuration or read failures.
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 and the schema is empty, so there are no parameter semantics to explain. Baseline 4 applies; the description correctly implies a parameterless bulk read.
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 concrete verb+resource (read every sensor) and enumerates the specific data returned: chip temperature, each analog channel, with raw ADC counts, millivolts and a scaled value. It implicitly distinguishes itself from esp32_gpio_read by scoping to analog channels, but never names a sibling explicitly.
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: 'read every sensor configured in the firmware' suggests a bulk snapshot call, and the absence of parameters reinforces that. It does not state when to prefer esp32_health or esp32_gpio_read instead, nor any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.