electronic-mcp-server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.2
Disambiguation5/5
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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![electronic-mcp-server MCP server](https://glama.ai/mcp/servers/wedsamuel1230/electronic-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/wedsamuel1230/electronic-mcp-server)

Score Badge

Copy to your README.md:

[![electronic-mcp-server MCP server](https://glama.ai/mcp/servers/wedsamuel1230/electronic-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/wedsamuel1230/electronic-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/wedsamuel1230/electronic-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server