Skip to main content
Glama
Sign In

rust.wiki

by wiki.rust
OverviewDiscussionsAdmin

Circuit simulator parts: every electrical part's inputs, outputs and rules

get_circuit_parts
Read-onlyIdempotent

Circuit simulator parts: every electrical part's inputs, outputs and rules. The parts and rules behind https://rust.wiki/calculators/circuit-simulator (Rust's power rules since the April 2024 rework): parts as [kind, name, shortname, group, inputs, outputs, settings], devices as [name, shortname, power draw], rules and caveats. The board and its solver run in the browser - build circuits on the page; for a plain power budget use /calculators/electricity/compute.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_circuit_parts"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover readOnly/idempotent/non-destructive, and the description adds genuinely new context: the data is a static reference table for a simulator that runs client-side, and it cannot compute a budget for you. It does not describe size, freshness, or pagination of the payload, but the safety and capability boundaries are clear.

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?

Three sentences, front-loaded with what the tool returns, then the exact field layout of each collection, then the scope boundary and alternative. No filler, and the tuple format is the highest-value information given there is no output schema.

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?

With no output schema and no parameters, the description carries the return-value burden and does it well by listing the shape of `parts`, `devices`, `rules` and `caveats`. Minor gap: it does not say what values `kind` or `caveats` can take, nor how large the tables are, but an agent can still call it confidently.

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?

Zero parameters, so there is nothing to disambiguate; the description correctly spends its words on return shape instead. Baseline of 4 applies.

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?

Names the resource precisely ('Circuit simulator parts: every electrical part's inputs, outputs and rules') and even states the underlying dataset (Rust power rules since the April 2024 rework). It lacks a crisp verb, and the distinguishing target is given as a page path rather than a tool name, so an agent must infer the mapping.

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?

Explicitly scopes the tool: the board and solver run in the browser, so this returns reference data only; for a plain power budget it points elsewhere ('use /calculators/electricity/compute'). The only gap is that the alternative is a URL path, not a sibling tool name such as get_electricity_data, leaving the routing inference to the agent.

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

All rust.wiki toolsInspect
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