Provides GPIO pin reference and troubleshooting for Arduino UNO R3, including pin information, PWM/ADC/I2C/SPI pin discovery, conflict checking, and ASCII pin diagrams.
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., "@electronic-mcp-server Decode resistor bands brown black red gold"
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.
A comprehensive Model Context Protocol (MCP) server providing 14 electronics engineering tools across 3 domains.
pip install electronics-mcp-serversRelated MCP server: PCB Parts MCP Server
After installation, verify the package is working:
# Alternative: Test individual servers
uvx --from electronics-mcp-servers resistor-decoder
uvx --from electronics-mcp-servers capacitor-calc
uvx --from electronics-mcp-servers gpio-reference# After pip install, test the CLI
electronics-mcp-servers --version
# Or test individual tools
resistor-decoder --help
capacitor-calc --help
gpio-reference --helpThis project uses different naming conventions in different contexts:
MCP Registry ID: io.github.wedsamuel1230/electronic-mcp-server (singular)
PyPI Package: electronics-mcp-servers (plural)
CLI Executables: electronics-mcp-servers, resistor-decoder, capacitor-calc, gpio-reference
When using uvx, always use the PyPI package name (electronics-mcp-servers).
Problem: uvx electronics-mcp-servers shows "executable not provided" error
Solution: The main electronics-mcp-servers executable was added in version 1.0.2. Make sure you have the latest version:
# Force uvx to fetch the latest version
uvx --refresh electronics-mcp-servers
# Or specify the version explicitly
uvx --from electronics-mcp-servers==1.0.2 electronics-mcp-servers
# Check installed version
pip index versions electronics-mcp-serversIf the error persists, PyPI may still be serving version 1.0.1. Wait a few minutes and try again.
decode_resistor_color_bands: Convert color bands to resistance value
encode_resistor_value: Convert resistance to color bands
find_standard_resistor: Find nearest E12/E24/E96 series value
calculate_capacitive_reactance: Frequency-dependent impedance
calculate_rc_time_constant: RC circuit time calculations
calculate_resonant_frequency: LC tank resonance
suggest_capacitor_for_filter: Filter design recommendations
get_pin_info: Detailed pin specifications (ESP32/Arduino/STM32)
find_pwm_pins: PWM-capable pin discovery
find_adc_pins: ADC channel mapping
find_i2c_pins: I2C bus pins
find_spi_pins: SPI bus pins
check_pin_conflict: Multi-pin conflict detection
generate_pin_diagram_ascii: Visual pinout diagrams
ESP32 DevKitC
Arduino UNO R3
STM32F103C8T6 (Blue Pill)
Add to your MCP client configuration (e.g., Claude Desktop):
{
"mcpServers": {
"electronics": {
"command": "python",
"args": ["-m", "servers"]
}
}
}Or with uvx:
{
"mcpServers": {
"electronics": {
"command": "uvx",
"args": ["electronics-mcp-servers"]
}
}
}from servers.resistor_decoder import decode_color_bands
from servers.capacitor_calculator import calculate_rc_time_constant
from servers.gpio_reference import get_pin_info
# Decode a resistor
result = decode_color_bands(["brown", "black", "red", "gold"])
# Returns: {"resistance": 1000, "tolerance": 5, "formatted": "1kΩ ±5%"}
# Calculate RC time constant
tau = calculate_rc_time_constant(10000, 100e-6)
# Returns: {"tau": 1.0, "time_63pct": 1.0, "time_full": 5.0}
# Get ESP32 pin info
pin = get_pin_info("ESP32", 32)
# Returns detailed pin capabilitiesPython 3.10+
FastMCP (mcp[cli]>=1.1.0)
MIT License - Copyright (c) 2026 Samuel F.
Calculate capacitive reactance (Xc) at a given frequency.
Formula: Xc = 1 / (2π × f × C)
Capacitive reactance represents the opposition to AC current flow through a capacitor. It decreases as frequency increases (capacitors pass high frequencies more easily).
Examples: 1µF at 1kHz → Xc ≈ 159Ω 100nF at 10kHz → Xc ≈ 159Ω
| Name | Required | Description | Default |
|---|---|---|---|
| frequency_hz | Yes | Frequency in Hertz (e.g., 1000 for 1kHz) | |
| capacitance_farads | Yes | Capacitance in Farads (e.g., 1e-6 for 1µF, 100e-12 for 100pF) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behavioral traits: the formula, the inverse relationship with frequency, and examples of typical values. It sufficiently conveys that the tool performs a pure calculation without side effects. Slightly more detail on return format would improve transparency, but it is adequate.
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 description is highly concise: three short paragraphs covering purpose, formula, explanation, and examples. Information is front-loaded with the verb and resource. Every sentence adds value without redundancy.
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?
Given the presence of an output schema (as indicated by context signals), the description does not need to explain return values. It covers the essential calculation behavior, formula, and examples. However, it could briefly mention the typical context (AC circuits) to tie the tool to common use cases.
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 coverage is 100%, so parameters are well-documented. The description adds value by providing the formula and concrete examples (e.g., 1µF at 1kHz) that illustrate how parameters map to the calculation. This extra context enriches understanding beyond the schema alone.
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 clearly states the tool calculates capacitive reactance at a given frequency using the formula. It provides a specific verb ('calculate') and resource ('capacitive reactance'). While it doesn't explicitly distinguish from sibling tools like `calculate_rc_time_constant`, the unique formula and behavior make it clear.
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 description explains what the tool does but does not provide explicit guidance on when to use it versus alternatives such as `calculate_rc_time_constant` or `suggest_capacitor_for_filter`. Usage is implied through the definition, but no exclusionary criteria or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate RC circuit time constant (τ = R × C).
The time constant Ï„ represents:
Time to charge to ~63.2% of final voltage
Time to discharge to ~36.8% of initial voltage
5τ ≈ 99.3% of final value (considered "fully" charged/discharged)
Examples: 10kΩ + 100µF → τ = 1 second 1kΩ + 1µF → τ = 1 millisecond
| Name | Required | Description | Default |
|---|---|---|---|
| resistance_ohms | Yes | Resistance in Ohms (e.g., 10000 for 10kΩ) | |
| capacitance_farads | Yes | Capacitance in Farads (e.g., 1e-6 for 1µF) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description fully discloses the behavior: it is a pure mathematical calculation with no side effects. The description explains the formula, the physical meaning of the result (charging/discharging percentages), and includes examples, which is sufficient transparency for a calculation tool.
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 description is concise and well-structured: it starts with the formula, explains the meaning of the time constant in bullet points, and gives three clear examples. Every sentence is informative, with no redundancy or unnecessary content.
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?
Given the tool's simplicity (two numeric inputs, no nested objects, output schema exists), the description is complete. It covers the formula, interpretation of the result, and multiple examples, which is sufficient for both understanding and using the tool correctly.
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 schema already specifies the parameters with descriptions and units. The description adds value by providing concrete examples (e.g., 10kΩ + 100µF → τ = 1 second) and clarifying the meaning of the units, which enhances understanding beyond the schema.
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 clearly states the tool calculates the RC time constant using the formula τ = R × C, with a specific verb ('Calculate') and resource ('RC circuit time constant'). It distinguishes itself from sibling tools like calculate_capacitive_reactance and calculate_resonant_frequency by focusing solely on the time constant.
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?
While the description explains the meaning of the time constant and provides examples, it lacks explicit guidance on when to use this tool versus alternatives (e.g., when other circuit calculations are needed). No 'when not to use' or comparison with siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate LC resonant frequency.
Formula: f = 1 / (2π√(LC))
At resonance:
Inductive reactance (XL) equals capacitive reactance (Xc)
Impedance is at minimum (series) or maximum (parallel)
Used in tuned circuits, filters, oscillators
Examples: 1mH + 1nF → f ≈ 159kHz 100µH + 100pF → f ≈ 1.59MHz
| Name | Required | Description | Default |
|---|---|---|---|
| capacitance_farads | Yes | Capacitance in Farads (e.g., 1e-9 for 1nF) | |
| inductance_henries | Yes | Inductance in Henries (e.g., 1e-3 for 1mH, 100e-6 for 100µH) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It explains the physics and provides examples, but does not describe the output format or what the tool returns (e.g., frequency in Hz). The existence of an output schema mitigates this somewhat, but the description misses the chance to add that context.
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 description is well-structured: formula, bullet points on resonance properties, and examples. It is concise but could be slightly more focused on tool behavior (e.g., removing the physics explanation if the agent only needs to know inputs/outputs).
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?
Given the tool's simplicity and the presence of a complete input and output schema, the description provides adequate context about when resonance matters and how to interpret results. It lacks explicit mention of the output value, but the schema completes that gap. Sibling tools are listed, but no cross-referencing is added.
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 coverage is 100% with good descriptions for both parameters. The description adds value by providing the formula relating them and concrete examples (1mH+1nF → 159kHz), which helps users understand units and scale. This goes beyond the schema's basic type and range.
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 clearly states the tool calculates LC resonant frequency, provides the formula f = 1/(2π√(LC)), and explains resonance behavior. It distinguishes itself from sibling tools (e.g., calculate_capacitive_reactance) by focusing on a different physical quantity.
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 description implies usage (tuned circuits, filters, oscillators) but does not explicitly state when to use this tool vs alternatives like calculate_capacitive_reactance or calculate_rc_time_constant. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if multiple pins have conflicting functions or usage restrictions.
Detects conflicts such as:
Using ADC2 pins with WiFi on ESP32
Using UART pins during serial debugging
Strapping pins that affect boot behavior
Shared peripheral buses (SPI, I2C)
Args: board_type: Development board type pin_list: List of pin numbers you plan to use
Returns: Conflict analysis with warnings and recommendations
| Name | Required | Description | Default |
|---|---|---|---|
| pin_list | Yes | List of pin numbers to check for conflicts | |
| board_type | Yes | Type of development board |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses what conflicts are detected and that it returns analysis with warnings/recommendations. Lacks mention of side effects, connectivity, or performance impact, but adequate for a static analysis tool.
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?
Description is concise and well-structured: brief intro, bulleted list of conflict types, clear Args/Returns sections. No fluff or redundancy.
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?
Given there is an output schema, the description's mention of 'Conflict analysis with warnings and recommendations' is sufficient. Inputs are fully described by schema. No critical omissions for a tool of this complexity.
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 covers all parameters with descriptions. Description adds minimal extra meaning (e.g., 'you plan to use' for pin_list). With 100% schema coverage, the description provides marginal value beyond the schema.
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?
Description clearly states the tool checks for conflicting pin functions/restrictions, lists specific conflict types (ADC2+WiFi, UART during debugging, etc.), and distinguishes from sibling tools like find_adc_pins and get_pin_info.
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 explicit guidance on when to use this tool versus alternatives like find_adc_pins or generate_pin_diagram_ascii. The context is implied (planning pin assignments) but lacks 'when not to use' or comparative advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode resistor color bands to get resistance value and tolerance.
Supports both 4-band and 5-band resistors:
4-band: digit, digit, multiplier, tolerance (common resistors)
5-band: digit, digit, digit, multiplier, tolerance (precision resistors)
Examples: 4-band: Brown, Black, Red, Gold → 1kΩ ±5% 5-band: Brown, Black, Black, Brown, Brown → 1kΩ ±1%
| Name | Required | Description | Default |
|---|---|---|---|
| band1 | Yes | First color band (digit 1): Black, Brown, Red, Orange, Yellow, Green, Blue, Violet, Grey, White | |
| band2 | Yes | Second color band (digit 2): same colors as band1 | |
| band3 | Yes | Third band - Multiplier for 4-band, or digit 3 for 5-band | |
| band4 | No | Fourth band - Tolerance for 4-band (Gold=±5%, Silver=±10%), or multiplier for 5-band | gold |
| band5 | No | Fifth band (5-band only) - Tolerance: Brown=±1%, Red=±2%, Gold=±5% |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the dual role of bands (multiplier vs digit) but does not disclose error handling, input validation, or behavior for invalid colors. Since no annotations are provided, more transparency would be beneficial.
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 description is concise with clear structure: purpose, support details, and examples. Every sentence adds value, and the key information is front-loaded.
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?
Given the presence of an output schema, the description sufficiently covers input and behavior. It includes examples for both resistor types, making it complete for the tool's complexity.
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 coverage is 100% and descriptions are detailed. The description adds value by clarifying that band3/band4 roles vary by resistor type (4-band vs 5-band), which is not fully captured in the schema.
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 clearly states the tool decodes resistor color bands to get resistance value and tolerance, with examples for both 4-band and 5-band resistors. It is specific and distinguishes it from sibling tools like encode_resistor_value.
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 description implies usage when color bands are available but does not explicitly state when to use versus alternatives or provide exclusions. Some guidance is present through examples but lacks explicit when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Encode a resistance value into color bands.
Converts a resistance value (in ohms) to the corresponding color band sequence.
Examples: 4700Ω, 5% → Yellow, Violet, Red, Gold 1000Ω, 1% → Brown, Black, Black, Brown, Brown (5-band)
| Name | Required | Description | Default |
|---|---|---|---|
| bands | No | Number of bands: 4 (standard) or 5 (precision) | |
| resistance_ohms | Yes | Resistance value in ohms (e.g., 4700 for 4.7kΩ) | |
| tolerance_percent | No | Tolerance percentage: 1, 2, 5, or 10 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the burden of behavioral disclosure. It describes the core transformation but omits details on input validation, error handling, or output format beyond examples. Adequate for a simple converter.
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 description is concise, front-loaded with the main purpose, and includes two informative examples with zero extraneous text. Every sentence adds value.
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?
Given the tool's low complexity and the presence of an output schema (mentioned in context), the description adequately covers input usage and examples. It does not explain output format in text, but the examples suffice. Minor gap: no mention of tolerance value restrictions beyond schema enum.
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 coverage is 100%, and the description adds meaning through examples showing how resistance_ohms, bands, and tolerance_percent map to output. The examples illustrate parameter usage effectively, exceeding the schema's basic definitions.
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?
Description clearly states the tool encodes a resistance value into color bands, specifying the verb 'encode' and resource 'resistance value'. It distinguishes from the sibling 'decode_resistor_color_bands' tool by focusing on the encoding direction.
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?
Description provides context for when to use (converting ohms to color bands) with clear examples. No explicit when-not or alternative tools mentioned, but the straightforward nature and sibling list implicitly guide usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all pins that support ADC (Analog-to-Digital Conversion) input.
ADC pins are used for reading:
Sensors (temperature, light, pressure)
Potentiometers and analog controls
Battery voltage monitoring
Analog signals
Args: board_type: Development board type
Returns: List of ADC-capable pins with channel information and notes
| Name | Required | Description | Default |
|---|---|---|---|
| board_type | Yes | Type of development board |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states what the tool does but does not disclose whether it queries hardware or uses static data, nor any limitations or error behavior. For a simple lookup tool, this may be adequate, but more detail would improve transparency.
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 description is concise with a clear heading, bulleted use cases, and separate Args/Returns sections. The Args/Returns lines are somewhat redundant with the schema but do not harm conciseness. Could be slightly tighter by omitting those.
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?
Given the existence of an output schema (not shown but indicated), the description does not need to detail return values. It covers purpose, parameter, and use cases. The agent has enough context to use the tool correctly.
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 input schema has 100% coverage with description for board_type. The description repeats the parameter info ('board_type: Development board type') but adds no new meaning beyond the schema. Baseline 3 is appropriate.
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 clearly states it lists all pins that support ADC input, with specific verb 'list' and resource 'pins that support ADC input'. It distinguishes from sibling tools like find_i2c_pins and find_pwm_pins by focusing on analog input capability.
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 description lists use cases (sensors, potentiometers, battery monitoring, analog signals) which gives clear context. However, it does not explicitly state when not to use it or provide direct comparison to siblings, but the use cases implicitly guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all pins that support I2C (Inter-Integrated Circuit) communication.
I2C is used for:
Sensor modules (IMU, temperature, pressure)
OLED/LCD displays
EEPROM chips
RTC modules
Args: board_type: Development board type
Returns: I2C pin pairs (SDA/SCL) with notes
| Name | Required | Description | Default |
|---|---|---|---|
| board_type | Yes | Type of development board |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool is a list operation returning I2C pin pairs (SDA/SCL) with notes, which is transparent. No behavioral traits like side effects or permissions are needed for a read-only query.
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 description is concise and well-structured: one sentence stating the purpose, a bullet list of use cases, and clear Args/Returns sections. Every element serves a purpose without redundancy.
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?
Given the tool's simplicity (one parameter, output schema present), the description fully explains the purpose, use cases, parameter, and return value. An output schema exists, so the return format does not need further detail in the description.
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 coverage is 100% with only one parameter, board_type, which already has an enum description. The description adds 'Development board type' which matches the schema, but does not add additional meaning beyond what the schema already provides.
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 clearly states the tool lists all pins supporting I2C communication, with specific verb 'list' and resource 'I2C pins'. It distinguishes from sibling tools like find_adc_pins and find_pwm_pins by specifying the protocol.
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 description provides a bullet list of typical I2C usages (sensors, displays, etc.), giving context for when the tool might be needed. However, it does not explicitly state when not to use it or compare with alternatives, leaving the usage inference implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all pins that support PWM (Pulse Width Modulation) output.
PWM pins are essential for:
LED dimming
Motor speed control
Servo control
Analog-like output generation
Args: board_type: Development board type
Returns: List of PWM-capable pins with timer information
| Name | Required | Description | Default |
|---|---|---|---|
| board_type | Yes | Type of development board |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the tool lists pins with timer information, implying a read-only query without side effects. However, it does not explicitly declare read-only behavior or mention any permissions or constraints. Basic transparency is achieved, but could be improved.
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?
Description is concise, starting with the main action in the first sentence. It uses bullet points for use cases and separate Args/Returns sections, providing a clear structure. The bullet list is relevant but slightly redundant; overall, it is well-organized and efficient.
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?
Given the tool has one parameter and an output schema (not shown but available), the description covers purpose, parameter, and return type adequately. The return description ('List of PWM-capable pins with timer information') is sufficient, though without seeing the output schema, the agent can infer the output structure. Completeness is high for a simple tool.
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 100%, meaning the schema already describes the single parameter (board_type as 'Type of development board'). The description only repeats 'Development board type' in the Args section, adding no new semantics beyond the schema. Baseline 3 is appropriate.
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?
Description clearly states the tool lists all PWM-capable pins, with specific verb 'List' and resource 'pins that support PWM output'. This distinguishes it from sibling tools like find_adc_pins or find_i2c_pins, which target different pin types.
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?
Description implies usage by listing common PWM applications (LED dimming, motor speed control, servo control), but does not explicitly state when to use this tool over alternatives or exclude scenarios. Sibling tools exist for other pin types (ADC, I2C, SPI), but no direct comparison is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all pins that support SPI (Serial Peripheral Interface) communication.
SPI is used for:
SD cards
Display modules (TFT, ePaper)
Flash memory chips
High-speed sensor communication
Args: board_type: Development board type
Returns: SPI pin assignments (MOSI, MISO, SCK, SS/NSS)
| Name | Required | Description | Default |
|---|---|---|---|
| board_type | Yes | Type of development board |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses the tool reads static data and returns pin assignments (MOSI, MISO, SCK, SS/NSS), which is sufficient. Could mention that it only queries for supported board types.
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 description is short, front-loaded with the main purpose, uses a bullet list for use cases, and clearly separates args and returns. No wasted words.
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 simple tool with one parameter and an output schema, the description fully explains what it does and returns. No additional details are needed.
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 coverage is 100% (one parameter with enum and description). The description simply repeats 'board_type: Development board type', adding no extra meaning beyond the schema.
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 clearly states 'List all pins that support SPI communication', using a specific verb and resource. It distinguishes from sibling tools like find_i2c_pins and find_adc_pins by focusing on SPI.
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 description provides common SPI use cases (SD cards, displays) but does not explicitly mention when not to use this tool or direct to alternatives. It implies usage for SPI-related tasks but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the nearest standard resistor value from E-series.
Standard resistor series:
E12: 12 values per decade (±10% tolerance)
E24: 24 values per decade (±5% tolerance)
E96: 96 values per decade (±1% tolerance)
Returns the closest standard value and nearby alternatives.
| Name | Required | Description | Default |
|---|---|---|---|
| series | No | Standard series: E12 (±10%), E24 (±5%), E96 (±1%) | E24 |
| target_ohms | Yes | Target resistance value in ohms |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the tool returns the closest standard value and nearby alternatives, and explains the series and tolerances. This is sufficient for a simple lookup tool, though it doesn't detail edge cases or output format.
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 description is concise: one sentence for purpose, a bulleted list for series, and a final sentence for return. No fluff, well-structured.
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 simple tool with output schema and 2 parameters, the description is complete. It explains the series, tolerances, and return value. No missing context.
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 coverage is 100%, so baseline is 3. The description adds value by explaining the series' tolerances and mentioning 'nearby alternatives' in return, which is not in the schema. This improves parameter understanding.
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 clearly states the tool's purpose: finding the nearest standard resistor value from E-series. It lists the series and indicates it returns the closest value and alternatives, distinguishing it from siblings that perform other calculations.
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 description implies usage when needing to find a standard resistor value, which is clear. However, it does not explicitly mention when not to use or compare to alternatives, though siblings are distinct enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an ASCII art pinout diagram for the development board.
Shows physical pin layout with pin numbers, names, and key functions in an easy-to-read text format.
Args: board_type: Development board type
Returns: ASCII art pinout diagram
| Name | Required | Description | Default |
|---|---|---|---|
| board_type | Yes | Type of development board |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses that the tool generates ASCII art and returns a diagram, which is safe and non-destructive. However, it lacks details on any side effects, authentication requirements, or limitations like board support or output format specifics.
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 description is concise: three sentences plus structured Args and Returns sections. The main action is front-loaded in the first sentence. No extraneous 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?
For a simple tool with one parameter and an output schema, the description adequately covers what the tool does and what it returns. It provides enough context for an AI agent to understand its purpose.
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 schema has 100% coverage with a description for board_type ('Type of development board') and an enum. The description repeats 'Development board type' in the Args section, adding no new meaning beyond the schema. Baseline of 3 is appropriate.
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 clearly states the tool generates an ASCII art pinout diagram for a development board, specifying the verb 'Generate' and the resource 'pinout diagram'. It distinguishes from sibling tools like get_pin_info (which provides pin details) and find_adc_pins (which finds specific pins), as it produces a visual layout.
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 explicit guidance on when to use this tool versus alternatives such as get_pin_info or find_adc_pins. The description implies the tool is for viewing physical pin layout, but it does not mention scenarios where it is preferred or not, nor does it suggest alternative tools for different needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific GPIO pin.
Returns pin name, alternative functions, capabilities (PWM, ADC, etc.), and important notes about usage restrictions or recommendations.
Args: board_type: Development board type (ESP32, Arduino UNO, or STM32) pin_number: Physical pin number
Returns: Formatted pin information including functions and notes
| Name | Required | Description | Default |
|---|---|---|---|
| board_type | Yes | Type of development board | |
| pin_number | Yes | Pin number to query |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the tool's read-only nature and the specific information returned (pin name, functions, capabilities, restrictions). It provides clear behavioral context without contradictions.
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 description is well-structured with a clear summary, return list, and args section. However, the Args section is redundant with the schema, slightly reducing conciseness.
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?
The description fully covers the tool's purpose, parameters, and return values. With an output schema present, the description sufficiently explains the tool's functionality and context.
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 coverage is 100%, and the description adds little beyond the schema's parameter descriptions. It repeats 'physical pin number' and 'development board type', offering marginal additional value.
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 explicitly states 'Get detailed information about a specific GPIO pin' and lists the return items (pin name, alternative functions, capabilities, usage restrictions). It clearly distinguishes from sibling tools that find pins or calculate values.
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 description implies usage for obtaining detailed pin info but does not explicitly compare with alternatives like check_pin_conflict or find_adc_pins, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend capacitor value for an RC filter design.
For a given cutoff frequency and resistance, calculates the required capacitance and suggests the nearest standard E12 series value.
Formula: C = 1 / (2π × f × R)
Examples: 1kHz cutoff with 10kΩ → C ≈ 15.9nF (use 15nF or 18nF) 100Hz cutoff with 1kΩ → C ≈ 1.59µF (use 1.5µF or 2.2µF)
| Name | Required | Description | Default |
|---|---|---|---|
| filter_type | No | Filter type: 'low-pass' or 'high-pass' | low-pass |
| resistance_ohms | Yes | Filter resistance in Ohms (e.g., 10000 for 10kΩ) | |
| cutoff_frequency_hz | Yes | Target cutoff frequency in Hz (-3dB point) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully bears the burden. It transparently explains the calculation (C = 1/(2Ï€fR)), the suggestion of nearest E12 standard value, and provides examples. However, it does not mention any limitations or edge cases.
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 description is extremely concise: two sentences for the core purpose and formula, plus two example lines. It is front-loaded with the key action and well-structured for quick comprehension.
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 simple calculation tool with full schema coverage and an output schema (not shown but present), the description provides sufficient context: formula, examples, and the suggestion logic. An agent can correctly invoke the tool based on this information.
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 coverage is 100% with parameter descriptions. The description adds value by showing the formula and concrete examples demonstrating how the parameters relate, which goes beyond the schema's individual property descriptions.
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 clearly states the tool's purpose: 'Recommend capacitor value for an RC filter design.' It specifies the verb (recommend), resource (capacitor value), and context (RC filter design), and distinguishes it from sibling tools that calculate other quantities like reactance or time constants.
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 description implies usage through examples and formula but does not explicitly state when to use this tool versus alternatives like calculate_capacitive_reactance. No when-not-to-use guidance is provided.
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.
v1.0.2calculate_capacitive_reactancecalculate_rc_time_constantcalculate_resonant_frequencycheck_pin_conflictdecode_resistor_color_bandsencode_resistor_valuefind_adc_pinsfind_i2c_pinsfind_pwm_pinsfind_spi_pinsfind_standard_resistorgenerate_pin_diagram_asciiget_pin_infosuggest_capacitor_for_filterScored across 14 tools
Each tool has a clearly distinct purpose: calculations, resistor color code, resistor standard values, and board-specific pin information. No two tools overlap in functionality, making it easy for an agent to select the correct one.
All tool names use lowercase snake_case and follow an action_object pattern, but the verb prefixes vary (calculate_, decode_, encode_, find_, check_, get_, generate_, suggest_). While still clear and readable, the mix reduces consistency slightly.
With 14 tools, the server is well-scoped for its purpose, covering calculations, resistor color codes, standard values, and board pin mapping. The number is appropriate for an electronics prototyping assistant.
The tool set covers key electronics calculations (RC, LC, capacitor filters), resistor color code handling, standard resistor values, and comprehensive board pin information for several board types. Minor gaps exist (e.g., inductor calculations beyond resonance), but the overall coverage is solid.
Electronic component datasheets for AI agents — specs, pinouts, package data on demand.
88 free engineering calculators: RF link budgets, LoRa/Meshtastic, PCB, solar, homelab. Keyless.
Search real parts with datasheet-provenance specs, check compatibility and compose priced BOMs.
Validates PESEL/NIP/REGON/IBAN/Luhn/ISBN/EAN/SWIFT-BIC/VAT; RPN calc, date math, hashing, tokens
