Skip to main content
Glama

sim_get_readiness

Audit schematic components for SPICE simulation readiness, classifying each as ready, needing a primitive, or requiring a vendor model file before simulation.

Instructions

Audit every component on the active schematic for SPICE readiness.

Use this as step 1 of any simulation workflow. The response classifies each component into one of three buckets:

  • ready , SpicePrefix already set; nothing to do.

  • needs_primitive, a passive (R/L/C) or source (V/I/D/Q) that just needs SpicePrefix + Value. Pass them all to sim_attach_primitives in one call.

  • needs_file , an IC or active part that requires a manufacturer-supplied .mdl / .ckt / .lib file. Call sim_attach_model after fetching the file from the vendor.

CRITICAL, vendor SPICE models only: Never fabricate a SPICE model from datasheet reasoning. The parameters that matter for convergence, bias point, and small-signal behavior are not in any datasheet summary; a plausible-looking hand-rolled model produces confidently-wrong simulation results. The response's _spice_guidance block makes this rule explicit and gives you per-part search queries.

Returns: Dict with: - ready, ready_count - needs_primitive, needs_primitive_count (each entry has designator, comment, suggested_prefix, suggested_value) - needs_file, needs_file_count (each entry has designator, comment, lib_ref, manufacturer, manufacturer_part) - _spice_guidance (rules + structured search_hints + primitive_hints)

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.7/5.0
Behavior4/5

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

No annotations exist, so the description carries the full burden and mostly delivers: it discloses the exact response shape, per-entry fields, the _spice_guidance block, and a strong correctness warning about hand-rolled vendor models. It stops short of stating that the call is read-only and side-effect-free on the schematic, which would complete the behavioral picture.

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?

Front-loaded purpose followed by a scannable bucket list and a clearly fenced CRITICAL warning. The Returns block is somewhat redundant with the existing output schema, but it is compact and aids at-a-glance planning.

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?

Output schema exists, yet the description still summarizes the fields that drive the agent's next action (suggested_prefix, suggested_value, manufacturer_part) and explains the guidance block. For a zero-parameter audit tool feeding a multi-step simulation workflow, nothing an agent needs to proceed 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?

Zero input parameters, so there is nothing to document and the baseline applies. The description does not waste space inventing parameter semantics, correctly focusing instead on the output contract.

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 verb and resource ('Audit every component on the active schematic for SPICE readiness') and immediately distinguishes itself from downstream siblings by naming sim_attach_primitives and sim_attach_model as the follow-on tools. The three-bucket classification makes the tool's scope unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use this as step 1 of any simulation workflow' and then prescribes the branch for each bucket (pass needs_primitive parts to sim_attach_primitives in one call; call sim_attach_model for needs_file). It even gives a negative constraint: never fabricate SPICE models from datasheet reasoning.

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