Skip to main content
Glama
Nivakaran-S

eda-agent

by Nivakaran-S
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

design_validate_requirement

Checks a structured design requirement for unresolved questions, missing power or outputs, invalid ranges and voltage mismatches before planning and part selection.

Instructions

Validate a structured DesignRequirement before planning starts.

Stage 1 of the autonomous flow (requirement capture & architecture, reference/autonomy-roadmap.md): capture what the board must do as a DesignRequirement dict, run this gate, and only move on to part selection / DesignPlan construction when it returns ok. Every fact the requirement does NOT state goes into open_questions as a question for the user -- it is never guessed -- and validation fails while any question remains unresolved.

Checks beyond the schema: unresolved open questions, no outputs, no power source, inverted temperature / IO-voltage ranges, comms IO without a protocol, and supply rails or power outputs whose magnitude exceeds every stated power input (a boost / inverting stage the user must confirm). Pure Python, no Altium.

board_intent (stackup, impedance targets, peak currents, fastest edge, enclosure, assembly, finish, test strategy) is all optional and never fails validation. Where the rest of the requirement makes one of them matter and it is missing, notes carries a suggested question to ask the user.

Args: requirement: DesignRequirement as a JSON object/dict. Units are SI with the unit in the field name (voltage_v, current_a, temp_min_c); mechanical dimensions are MILLIMETRES (board_size_mm, height_max_mm).

Returns: {"ok": True, "issues": [], "notes": [...], "summary": "..."} when the requirement is planning-ready (summary is the labelled-line block to embed in DesignPlan.summary), or {"ok": False, "issues": [...]} / {"ok": False, "errors": [...]} (schema problems) listing what to resolve.

Input Schema

NameRequiredDescriptionDefault
requirementYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so richly: it lists the concrete validation checks, states that board_intent is optional and never fails validation, explains that notes suggest user questions, and clarifies that the tool is pure Python with no Altium interaction.

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?

The definition is long but well structured and front-loaded: purpose, stage context, validation rules, optional fields, args, and returns are clearly separated. Every section adds information an agent needs for this complex gate.

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?

Given the complex validation behavior, minimal input schema, and output schema, the description provides enough detail to call the tool and interpret ok/failure responses. It covers validation checks, optional vs failing fields, unit conventions, and return shapes.

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 0%, so the description must compensate, and it does: it defines the requirement as a DesignRequirement JSON object, explains SI unit conventions with field-name suffixes, specifies millimetres for mechanical dimensions, and gives example field names such as voltage_v and board_size_mm.

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 states a specific verb and resource: validate a structured DesignRequirement before planning starts. It also positions the tool as Stage 1 of the autonomous flow, distinguishing it from downstream planning or part-selection steps.

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?

It gives explicit when-to-use guidance: run this gate before part selection / DesignPlan construction, and proceed only when it returns ok. It also states that unresolved open_questions block validation, which tells the agent exactly what must be resolved first.

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