Skip to main content
Glama
Sign In
circuit-agent

circuit-agent

by mo9652962-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

analyze_resistor_error_budget

Read-onlyIdempotent

End-of-life resistance band for one resistor from the four-term error model: value tolerance, temperature coefficient, life drift, and (for matched networks) ratio tolerance.

Instructions

End-of-life resistance band for one resistor from the four-term error model: value tolerance, temperature coefficient, life drift, and (for matched networks) ratio tolerance. Reports both the RSS band and the linear worst-case band, and names the dominant term — because buying a ±0.1% thick-film part to fix an accuracy problem does nothing when its 200 ppm/°C TCR already contributes 1.2% over a 60 °C excursion. Life drift scales with sqrt of the time ratio (random walk, not a ramp).

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": {
      "nominal_ohm": "<nominal_ohm>"
    },
    "name": "analyze_resistor_error_budget"
  }
}

Input Schema

NameRequiredDescriptionDefault
nominal_ohmYesMarked resistance in ohms.
delta_temp_cNoTemperature excursion from 25 °C.
tcr_ppm_per_cNoTemperature coefficient in ppm/°C.
tolerance_pctNoValue tolerance in percent.
life_drift_pctNoLife drift percent over life_hours_specified.
life_hours_requiredNoThe service life the design must meet.
life_hours_specifiedNoThe hours the datasheet's life figure refers to.

Output Schema

NameRequiredDescriptionDefault
dominanceYes
value_bandYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.16.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so safety is covered. The description adds real behavioral value beyond that: it reports both an RSS band and a linear worst-case band, names the dominant term, and discloses that life drift scales with sqrt of the time ratio rather than linearly — a non-obvious modeling choice an agent would otherwise mis-assume.

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?

Front-loaded with the computation and its inputs in the first sentence, then outputs, then a modeling caveat. The thick-film TCR anecdote is longer than strictly necessary but earns its place by motivating the dominant-term output; only minor trimming would improve it.

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?

With annotations covering safety, a 100%-covered seven-parameter schema, and an output schema, the description supplies exactly the remaining context: which four terms feed the model, what the two output bands mean, how drift is scaled, and which term dominates. Nothing needed to invoke or interpret the tool is missing.

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 earns a bump by clarifying the relationship the schema only names individually: life_drift_pct is scaled by sqrt(life_hours_required/life_hours_specified) as a random walk, and TCR contribution is tied to temperature excursion — semantics not captured by the flat per-field 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?

States a specific computation — the end-of-life resistance band for a single resistor from a four-term error model — and enumerates the four terms (value tolerance, TCR, life drift, ratio tolerance). This is clearly separable from siblings like analyze_divider_tolerance or analyze_impedance_tolerance, which operate on networks/impedance rather than a single resistor's error stack.

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?

Usage is implied rather than stated: the tool is scoped 'for one resistor' and mentions 'matched networks' for ratio tolerance, and the ±0.1% thick-film example signals the diagnostic intent. However, no sibling alternative is named and there is no explicit when-to-use/when-not guidance relative to analyze_divider_tolerance or analyze_impedance_tolerance.

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

Deploy Server

Other Tools