Skip to main content
Glama
Sign In
circuit-agent

circuit-agent

by mo9652962-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

solve_feedback_divider

Read-onlyIdempotent

Exact R1/R2 feedback divider pair for a regulator or comparator target, plus the static error the E96 snap adds. The ideal pair almost never exists in E96, and that snap error is a wrongness, not a tolerance: it is identical on every board…

Instructions

Exact R1/R2 feedback divider pair for a regulator or comparator target, plus the static error the E96 snap adds. The ideal pair almost never exists in E96, and that snap error is a wrongness, not a tolerance: it is identical on every board and must be budgeted separately from the tolerance band.

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": {
      "v_out": "<v_out>",
      "v_ref": "<v_ref>"
    },
    "name": "solve_feedback_divider"
  }
}

Input Schema

NameRequiredDescriptionDefault
v_outYesTarget output voltage.
v_refYesReference voltage at the feedback midpoint.
r_total_ohmNoTotal divider resistance R1+R2, which sets the quiescent current.

Output Schema

NameRequiredDescriptionDefault
noteYesWhy the snap error must be budgeted separately from the tolerance band.
v_refYesReference voltage at the feedback midpoint.
r1_ohmYesSnapped E96 high-side resistor.
r2_ohmYesSnapped E96 low-side resistor.
v_out_actualYesOutput the snapped pair actually produces.
v_out_targetYesRequested output voltage.
snap_error_pctYesStatic offset from E96 quantisation — a wrongness, not a tolerance.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.16.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful domain behavior beyond that: the E96 snap error is deterministic and identical on every board, so it is a systematic 'wrongness' that must be budgeted separately from tolerance. This is useful context an agent would not get from annotations alone.

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?

Two sentences, front-loaded with the core purpose, then an important caveat. The second sentence is dense but every clause earns its place by explaining the snap error's nature and budgeting implication; no filler is present.

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?

An output schema exists, so return values need not be enumerated. The description explains the two key outputs (exact pair and static snap error) and the critical interpretation of the error, making it sufficiently complete for correct invocation. It does not mention input assumptions like v_ref being the feedback midpoint, but the schema covers that.

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%, so v_out, v_ref, and r_total_ohm are already documented in the schema. The description does not add any syntax, constraints, or meaning beyond what the schema provides, so the baseline of 3 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?

The description uses a specific verb+resource ('solve_feedback_divider' → 'Exact R1/R2 feedback divider pair') and scopes it to a regulator or comparator target. It also names the extra output (static E96 snap error), which implicitly separates it from tolerance-analysis siblings, though it does not explicitly name an alternative tool.

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?

It gives implied usage context: for a regulator or comparator target, and notes that the snap error must be budgeted separately from the tolerance band. However, it does not say when to use this versus analyze_divider_tolerance or analyze_resistor_error_budget, nor does it state any exclusions.

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