Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutRoadmapCareersInternshipsFAQContactPrivacyTerms
Skip to lesson

Course contents

  • Getting Started with AI for VLSI Engineers5
  • Just Enough AI: Models and Context15
  • Prompting13
  • Trust and Verification14
  • Using AI for Engineering Work17
  • Engineering Walkthroughs7
  • Practical Foundations for AI Workflows4
  • Engineering Data5
  • Retrieval-Augmented Generation6
  • Agents and Tool Use18
    • What an Agent Is
    • Tool Use and Structured Output
      • Describing Tools to a Model
      • Propose, Execute, Validate
      • Handling Malformed Calls
      • Idempotent and Side-Effecting Tools
      • Tool-Call Validator Lab
    • Planning, Memory and Stopping
    • Multi-Agent Patterns and When Not to Use Agents
  • Agent Design8
  • MCP and Skills6
  • Multi-Agent Design6
  • Practical Capstone6
  • Tokens, Cost and Latency12
  • Agentic Workflows for Chip Teams18
  • Interview and Judgment10
  • AI Skills: Full Course Index
  • Working with AI Glossary
  • Working with AI Cheatsheet
Loading lesson

←Tool Use and Structured Output
  1. Topics
  2. AI Skills for VLSI Engineers
  3. Agents and Tool Use
  4. Tool Use and Structured Output
  5. Describing Tools to a Model
On this page

    Tools, Workflows and AgentsBeginner to Intermediate

    Describing Tools to a Model

    What a tool description carries: name, purpose, and a parameter schema the program can check.

    What the model receives

    A tool description has three parts: a name, a purpose in plain words, and a parameter schema. The program owns this text, and the model only reads it.

    Part

    Example for read_register

    Why it matters

    Name

    read_register

    Routes the call to exactly one implementation.

    Purpose

    Read one 8-bit control register by address.

    Tells the model when this tool fits the task.

    Parameter schema

    addr: integer, 0 to 15, required.

    Lets the program accept or reject each argument.

    Schemas carry types and bounds

    A schema names each argument, its type, and its allowed range. Required arguments are marked, and missing ones are rejected before anything runs.

    Types here are ordinary JSON types: integer, string, boolean, and small objects. Bounds keep values inside the range the tool serves.

    Argument

    Type

    Bounds

    Required

    addr of read_register

    integer

    0 to 15

    Yes

    addr of write_register

    integer

    0 to 15

    Yes

    data of write_register

    integer

    0 to 255

    Yes

    block of run_lint

    string

    Must name a known block

    Yes

    A worked trace

    The trace below is schematic, not output from any real system. It shows one task turning into one validated call.

    plaintext
    1
    2
    3
    4
    5
    schematic trace (illustrative, not from any real system)
    task: read control register 8
    model proposes: {"tool": "read_register", "arguments": {"addr": 8}}
    program checks: tool known, addr present, addr is integer, 0 <= 8 <= 15
    verdict: ok -> run read_register, return the 8-bit value as observation

    Registry probe

    The program below stands in for the loop with a fake scripted model. It routes two tools and names three faults over six checks.

    example.py
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    import json
    
    TOOLS = {
        "read_register": {"purpose": "Read one 8-bit control register by address.", "required": ["addr"]},
        "run_lint": {"purpose": "Run the lint suite over one named block.", "required": ["block"]},
    }
    
    def fake_model(task):
        if "register 8" in task:
            return {"tool": "read_register", "arguments": {"addr": 8}}
        return {"tool": "run_lint", "arguments": {"block": "alu"}}
    
    def dispatch(call):
        name = call.get("tool")
        args = call.get("arguments")
        if name not in TOOLS:
            return "unknown-tool"
        if not isinstance(args, dict):
            return "bad-arguments"
        for key in TOOLS[name]["required"]:
            if key not in args:
                return "missing-field"
        return "ok:" + name
    
    bad = 0
    if dispatch(fake_model("read register 8")) != "ok:read_register":
        bad += 1
    if dispatch(fake_model("lint the alu")) != "ok:run_lint":
        bad += 1
    if dispatch({"tool": "nope", "arguments": {}}) != "unknown-tool":
        bad += 1
    if dispatch({"tool": "read_register", "arguments": {}}) != "missing-field":
        bad += 1
    if dispatch({"tool": "read_register", "arguments": [8]}) != "bad-arguments":
        bad += 1
    if dispatch(json.loads(json.dumps(fake_model("read register 8")))) != "ok:read_register":
        bad += 1
    
    if bad == 0:
        print("PASS: 6 registry checks route 2 tools and name 3 faults")
    else:
        print("FAIL: " + str(bad) + " of 6 registry checks went wrong")
        raise SystemExit(1)

    Common mistakes

    A description that promises what the code never checks invites bad calls. If the purpose calls an argument optional, the validator must accept its absence.

    Likely probes: what a tool description carries, and who owns it.

    • Name, purpose, and parameter schema, owned by the program.

    • The model proposes calls; it never executes anything.

    • Schemas mark types, bounds, and required arguments.

    Check yourself A new tool needs an address from 0 to 7. Which three pieces does its description need?

    A name, a one-line purpose, and a schema marking addr an integer from 0 to 7 and required.

    Check yourself The model proposes a call to a tool missing from the registry. What does the program do?

    It rejects the call as an unknown tool. Only registered names ever execute.

    Related topics

    • Propose, execute, validate

    • What an agent is

    Previous

    92 / 173

    Next: Propose, Execute, Validate

    Up next

    Up nextPropose, Execute, Validate

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • Handling Malformed Calls
    • Idempotent and Side-Effecting Tools
    • Tool-Call Validator Lab