ScorpTech x402 Tools

Led Resistor

led_resistor

Read-onlyIdempotent

Series resistor for LEDs on one supply. Resistance is (supply − series × forward) / current, with volts and amperes. The part chosen is the next IEC 60063 E24 value at or above that resistance, so the LED current does not go over the request. The forward drop of the string must be under the supply. Exact rationals. Price: $0.001 USDC per successful call (x402, Solana). Same tool over HTTPS: GET https://scorptech.it.com/api/x402/v1/led-resistor

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "supply": "<supply>",
      "forward": "<forward>",
      "current": "<current>"
    },
    "name": "led_resistor"
  }
}

Input Schema

Name	Required	Description
`series`	No	How many LEDs in series
`supply`	Yes	Supply, volts
`current`	Yes	Wanted LED current, amperes
`forward`	Yes	Forward drop of one LED, volts

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 23, 2026

TDQS

A4.3/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description discloses that the result is rounded up to the next IEC 60063 E24 value so LED current does not exceed the request, that exact rationals are used, and that the part must satisfy the forward-drop constraint. It also states the paid x402/Solana pricing model and an HTTPS alternative endpoint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the calculation, then the E24 rounding rule and constraint, then pricing and endpoint. Every sentence contributes useful information and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a calculator with no output schema, the description covers the formula, rounding behavior, and validation constraint well. It does not explicitly describe the return value shape (e.g., resistor value versus E24 part designation), which is a minor remaining gap.

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 already 100%, so the baseline is 3, but the description adds meaningful formula-level semantics: resistance = (supply − series × forward) / current, with volts and amperes, and that series is the number of LEDs in the string.

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 states a specific resource and action: computing a series resistor for LEDs from supply, forward drop, and current, with E24 rounding. It is clear what the tool does, but it does not explicitly differentiate itself from nearby siblings such as resistor_code, resistor_network, ohm_law, or voltage_divider.

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 context is clear: use it for a series resistor for LEDs on one supply, and the forward drop of the string must be under the supply. It gives a constraint but does not name alternatives or say when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All ScorpTech x402 Tools tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?