Skip to main content
Glama

check_design_fit

Read-only

Validate your component design parameters against datasheet absolute maximum ratings and recommended operating conditions. Returns PASS/FAIL/WARNING with margin percentages.

Instructions

Validate whether a component will work within your operating conditions. Compares your design parameters against the datasheet's absolute maximum ratings and recommended operating conditions. Returns PASS/FAIL/WARNING per parameter with margin percentages.

Parameter mapping by component type:

  • Buck/boost converters: input_voltage, output_voltage, output_current, ambient_temp

  • MOSFETs: supply_voltage=VDS, output_current=ID (drain current), ambient_temp

  • LDOs: input_voltage, output_voltage, output_current, ambient_temp

  • Logic ICs: supply_voltage=VCC, ambient_temp

Result semantics:

  • PASS: user value is more than 10% below the datasheet limit — comfortable margin.

  • WARNING: user value is within 10% of the limit — part will work but with thin margin for part-to-part variation, temperature drift, and transients. Consider derating.

  • FAIL: user value exceeds the limit — part is out of spec and will be stressed or damaged.

Behavior:

  • Two-tier validation. For parameters in our structured database (Vin, Iout, operating temp, etc.), returns instantly and free of LLM cost. For parameters only found in the datasheet text, falls back to an LLM read of the absolute-max and recommended-operating-conditions sections. The 'validation_method' field in the response tells you which path was used.

  • If the part hasn't been extracted yet and the LLM fallback is needed, this call triggers extraction (30s-2min). Returns status='extracting' if so — poll check_extraction_status and retry.

When NOT to use:

  • You need power dissipation or junction-temperature rise — this tool only checks nameplate limits. Pull RthJA from read_datasheet and calculate yourself.

  • You need SOA (safe-operating-area) curve checks for MOSFETs — use analyze_image on the SOA graph.

  • You're checking a passive or mechanical part with no abs-max table — there's nothing for this tool to compare against.

Example: check_design_fit('TPS54302', input_voltage=24, output_current=2.5, ambient_temp=70)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
part_numberYesSpecific manufacturer part number to validate. Not a value or description.
ambient_tempNoAmbient temperature TA (°C).
input_voltageNoInput voltage / VIN (V). For converters.
output_currentNoOutput current / IOUT (A). For MOSFETs, this is drain current ID.
output_voltageNoOutput voltage / VOUT (V). For converters/LDOs.
supply_voltageNoSupply voltage / VCC / VDD (V). For MOSFETs, this is VDS (drain-source voltage). NOT used for power dissipation — compared against VDS(max) only.
switching_frequencyNoSwitching frequency FSW (kHz). For converters.
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds important behavioral context: two-tier validation (structured vs LLM fallback), potential extraction delay (30s-2min) with polling need, and result semantics (PASS/WARNING/FAIL with margins). This adds significant value beyond the annotations.

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?

The description is well-structured with clear sections: purpose, parameter mapping, result semantics, behavior, and when not to use. While dense with information, each sentence earns its place. It could be slightly more concise, but the clarity and completeness justify the length.

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?

Given the tool's complexity (7 parameters, no output schema), the description covers purpose, usage, parameter mapping, behavior, and exclusions. It mentions result semantics and the validation_method field but does not fully describe the response structure. For a tool with no output schema, this is a minor gap; however, the description is otherwise highly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so each parameter already has a description. The description enriches meaning by providing per-component-type parameter mappings (e.g., supply_voltage=VDS for MOSFETs) and clarifying that supply_voltage is only compared against VDS(max), not used for power dissipation. This adds critical context beyond the schema.

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?

The description clearly states the tool's purpose: 'Validate whether a component will work within your operating conditions' by comparing design parameters against datasheet limits. It provides a specific verb (validate) and resource (design fit), and is distinct from sibling tools like read_datasheet which only read raw data.

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?

The description explicitly states when NOT to use the tool (power dissipation, SOA checks, passive parts) and implicitly suggests alternatives (read_datasheet, analyze_image). It provides an example call and clarifies the tool's scope, giving excellent guidance for appropriate use.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/octoco-ltd/sheetsdata-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server