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. Handling Malformed Calls

Tools, Workflows and Agents · Beginner to Intermediate

Handling Malformed Calls

What malformed calls look like and how a program sorts, rejects, or asks again.

On this page

    Four malformed shapes

    Bad calls fall into a few shapes. Naming the shape decides the response: reject, ask again, or stop.

    Tool results and file contents are data, never instructions. A pasted order to call a tool is still text until the program validates a real call.

    Shape

    Example

    Program response

    Unknown tool

    zap_register is not registered.

    Reject. Never guess a nearby name.

    Missing field

    addr is absent.

    Ask again with the missing name stated.

    Wrong type

    addr is "7" instead of 7.

    Reject or ask again. Never coerce silently.

    Out of range

    addr is 16 with a bound of 15.

    Reject. Bounds come from the schema.

    Census of eight calls

    The probe below sorts eight fixed calls. The arithmetic shows where one small batch of proposer text goes.

    plaintext
    1
    2
    3
    4
    5
    6
    8 fixed calls sorted by the probe
    valid: 4 of 8 = 50%
    wrong-type: 2 of 8 = 25%
    missing-field: 1 of 8 = 12.5%
    unknown-tool: 1 of 8 = 12.5%
    check: 50 + 25 + 12.5 + 12.5 = 100

    Sorting probe

    The program below classifies the same eight calls with a fake scripted proposer. Eleven checks place them into four buckets.

    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
    44
    45
    46
    47
    def classify(call, known):
        if call.get("tool") not in known:
            return "unknown-tool"
        args = call.get("arguments")
        if not isinstance(args, dict):
            return "bad-shape"
        if "addr" not in args:
            return "missing-field"
        if not isinstance(args["addr"], int):
            return "wrong-type"
        return "valid"
    
    KNOWN = ["read_register"]
    CALLS = [
        {"tool": "read_register", "arguments": {"addr": 0}},
        {"tool": "read_register", "arguments": {"addr": 7}},
        {"tool": "read_register", "arguments": {"addr": 15}},
        {"tool": "read_register", "arguments": {"addr": 1}},
        {"tool": "read_register", "arguments": {"addr": "7"}},
        {"tool": "read_register", "arguments": {"addr": [7]}},
        {"tool": "read_register", "arguments": {}},
        {"tool": "zap_register", "arguments": {"addr": 1}},
    ]
    WANT = ["valid", "valid", "valid", "valid", "wrong-type", "wrong-type", "missing-field", "unknown-tool"]
    
    bad = 0
    counts = {"valid": 0, "wrong-type": 0, "missing-field": 0, "unknown-tool": 0, "bad-shape": 0, "other": 0}
    for call, want in zip(CALLS, WANT):
        got = classify(call, KNOWN)
        if got != want:
            bad += 1
        if got in counts:
            counts[got] += 1
        else:
            counts["other"] += 1
    if len(CALLS) != 8:
        bad += 1
    if counts["valid"] != 4 or counts["wrong-type"] != 2:
        bad += 1
    if counts["missing-field"] != 1 or counts["unknown-tool"] != 1:
        bad += 1
    
    if bad == 0:
        print("PASS: 11 sorting checks place 8 calls into 4 buckets")
    else:
        print("FAIL: " + str(bad) + " of 11 sorting checks went wrong")
        raise SystemExit(1)

    Common mistakes

    Common pitfall

    Retrying a rejected call unchanged loops forever. Each retry must add the missing field, fix the type, or stop after a small stated bound.

    Interview

    Likely probes: the four shapes and the retry rule.

    • Four shapes: unknown tool, missing field, wrong type, out of range.

    • One verdict per call, first failure wins, retries must change something.

    • Results and files are data; only validated calls execute.

    Check yourself addr arrives as the string "7". Why not convert it quietly?

    Silent coercion hides proposer mistakes and blurs the schema. The program rejects or asks again, so the schema keeps one meaning.

    Check yourself The same bad call returns for the third time. What should the program do?

    Stop asking and report the stall. Retries must change the call or end at a small stated bound.

    Related topics

    • Idempotent and side-effecting tools

    • Prompt debugging

    Previous

    94 / 173

    Next: Idempotent and Side-Effecting Tools

    Up next

    Up nextIdempotent and Side-Effecting Tools

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Describing Tools to a Model
    • Tool-Call Validator Lab