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

AboutContactPrivacyTerms
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

Tools, Workflows and Agents · Beginner to Intermediate

Describing Tools to a Model

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

On this page

    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

    Common pitfall

    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.

    Interview

    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 lessonReport an error

    See also

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