Function Calling
Advanced 13 min read Function Calling

Function Call Protocols

Dialects of the same round trip

A function-calling protocol — like the Anthropic tool-use format or OpenAI's — formalizes how models declare calls. Cross-provider abstractions (AI SDK, LangChain) normalize dialects so your app survives model swaps.

protocoltool-use formatAI SDKstandardcross-providerinterop
Prerequisites: Function Calling Overview
Before we start

What you will learn

  • Compare major protocol dialects
  • Use a portable abstraction layer
  • Map your app across providers cleanly
Introduction

What is this?

Each provider speaks a slightly different tool-call dialect (message shape, roles, arg serialization). A protocol layer — direct provider calls OR an abstraction like the AI SDK or LangChain — normalizes 'ask model → handle tool_calls → return results' into one shape. That frees your dispatch layer from provider quirks.

Motivation

Why do you need it?

  • Model swaps become config, not rewrites.
  • One eval harness covers every provider.
  • Abstractions already encode correct multi-turn tool loops.
  • Protocol details (role names, JSON.stringify of args) are easy to get wrong by hand.
Think about it

Mental model

Imagine

The universal 'insert card' icon

Think of

Protocol abstraction

Wireless payment looks identical across banks despite wildly different internals, because a standard icon + protocol (NFC) sits between you and the bank. Your checkout code stops caring which bank — one TAP. That's the value of a tool-call abstraction.

Mechanics

How it works

  • Pick a representation: provider-native (OpenAI tools, Anthropic tool_use) or an DSP abstraction (AI SDK tools).
  • Declare tools once in your format; let the layer translate.
  • Handle the result message containing tool_calls.
  • Execute via your dispatcher, feed tool results back through the layer.
  • Keep provider-specific edge cases (forced tool_choice, parallel calls) explicit.

Abstraction plane.

Your app
Adapter
Provider A
Provider B
Real world

In production

  • AI SDK or LangChain tool abstractions power standard agent stacks.
  • Vendor is config: swap model/provider behind the adapter.
  • Protocol-aware middleware logs unified tool-call traces.
Guidelines

Best practices

  • Define your tools once at the app layer.
  • Validate args in YOUR schemas regardless of provider dialect.
  • Pin SDK versions; dialects drift between releases.
  • Test the same golden tool-case against every provider.
Watch out

Common mistakes

  • Hand-writing provider glue and re-teaching quirks per vendor.
  • Schema translations silently dropping enums or requireds.
  • Assuming parallel tool calls are supported identically everywhere.
Root cause analysis

Common issues

Error
Args serialize as strings or objects inconsistently
Root cause

Provider dialect differences

Fix

Normalize at the adapter; validate typed args in dispatch.

Error
Abstraction hides a provider-only quirk
Root cause

Leaky abstraction

Fix

Escalate to the provider-native API for that edge case.

When things break

Debugging tips

  • Tool works in provider X not Y → compare translated schema; dialect diff.
  • Result message shape varies → normalize into a typed envelope in the adapter.
  • Upgrades break loops → pin versions; read changelogs for dialect changes.
Interviews

Interview checkpoint

Practice

Hands-on lab

Cross-Provider Tool Dialect Shim
35 min · advanced
In progress
Objectives
  • Normalize two provider dialects
  • Translate your tool list for each
  • Adapt results back to a common envelope

Cross-Provider Tool Dialect Shim

35 min · advanced

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

A protocol layer's main job is…

2

Schema fidelity survives translation to every provider automatically.

Go deeper

Official documentation

AI SDK tools
docs