Prompt Chain

Test LLM Tool Use

A Promptfoo example evaluating tool/function calling across OpenAI, Anthropic, AWS Bedrock, and Groq using a shared weather-lookup function.

Works with github

80
Spark score
out of 100
Updated 9 days ago
Version 0.121.19
Models
claude 3 5 sonnet

Add to Favorites

Why it matters

Evaluate and ensure your Large Language Models can reliably use external tools and functions. This asset helps you test their ability to call and integrate with your existing software.

Outcomes

What it gets done

01

Automate the testing of LLM function/tool calling.

02

Verify LLM adherence to tool specifications.

03

Generate test cases for tool interactions.

Install

Add it to your toolbox

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/pfoo-eval-tool-use | bash

Overview

Eval Tool Use

A Promptfoo example evaluating LLM function/tool calling across OpenAI, Anthropic, AWS Bedrock, and Groq, using a shared weather-lookup function and finish-reason assertions. Use it to verify models correctly trigger tool calls across multiple providers. Requires provider-specific API keys depending on which providers you test.

What it does

A Promptfoo example evaluating LLM function/tool calling across four providers - OpenAI (native function calling), Anthropic (Claude tool use), AWS Bedrock, and Groq - each with slightly different syntax and requirements. All providers are tested against the same weather-lookup function (taking a location and optional temperature unit) to show how each handles an identical function definition differently.

When to use - and when NOT to

Use it as a starting point for testing whether your models correctly call tools or functions when they should - for example verifying that asking about weather in real cities (Boston, New York, Paris) reliably triggers a tool call rather than a hallucinated answer. It requires provider-specific API keys depending on which providers you test: OPENAI_API_KEY, ANTHROPIC_API_KEY, AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY for Bedrock, and GROQ_API_KEY for Groq's LLaMA models - set via a .env file or directly in your shell environment, whichever providers you're actually testing against.

Inputs and outputs

Two configs are provided: promptfooconfig.yaml (main example - OpenAI, Anthropic, Groq) and promptfooconfig.bedrock.yaml (AWS Bedrock specifically). External tool definitions can also be loaded from a separate file, demonstrated via external_tools.yaml. Run with:

npx promptfoo@latest init --example eval-tool-use
cd eval-tool-use
promptfoo eval
promptfoo eval -c promptfooconfig.bedrock.yaml
promptfoo view

Results are validated partly via finish-reason assertions - the tool_calls finish reason confirms a model stopped generation specifically to make a function/tool call, rather than answering directly. That check is anchored to the same weather-lookup scenario used elsewhere in the example, on the same three real cities.

Integrations

Covers OpenAI, Anthropic (only one of the Anthropic examples turns on strict: true - it isn't the default for every Anthropic test in this suite - and that mode uses Claude's structured-outputs feature, which guarantees tool parameters exactly match your input_schema with no type mismatches or missing required fields - useful for reliable agentic workflows, type-safe function calls, and production systems needing guaranteed schema conformance), AWS Bedrock, and Groq; each provider's own tool-use documentation is linked for its specific syntax: OpenAI's Function Calling Guide, Anthropic's Tool Use Guide, AWS Bedrock's Claude Tool Use docs, and Groq's Function Calling docs. For a deeper dive into Anthropic's structured-outputs feature specifically, the example points to a separate, dedicated structured-outputs example.

Who it's for

Teams building agentic or tool-using LLM applications across multiple providers who need to verify each provider correctly triggers tool calls, with an option to lock down strict schema conformance on Anthropic via strict: true.

Source README

eval-tool-use (Function and Tool Calling)

This example demonstrates how to evaluate LLM function/tool calling capabilities using promptfoo.

You can run this example with:

npx promptfoo@latest init --example eval-tool-use
cd eval-tool-use

Overview

This example shows how to configure and test function/tool calling capabilities across multiple LLM providers:

  • OpenAI (with native function calling)
  • Anthropic (with Claude's tool use)
  • AWS Bedrock models
  • Groq (with function calling)

Each provider has slightly different syntax and requirements for implementing function/tool calling.

Environment Variables

This example requires the following environment variables:

  • OPENAI_API_KEY - Your OpenAI API key
  • ANTHROPIC_API_KEY - Your Anthropic API key
  • AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY - For AWS Bedrock (if using the Bedrock example)
  • GROQ_API_KEY - If using Groq's LLaMA models

You can set these in a .env file or directly in your environment.

Provider Documentation

Each provider implements tool use with different syntax:

Running the Example

The configuration for this example is in:

  • promptfooconfig.yaml - Main example with OpenAI, Anthropic, and Groq
  • promptfooconfig.bedrock.yaml - Example specifically for AWS Bedrock models

To run the main example:

promptfoo eval

To run the Bedrock example:

promptfoo eval -c promptfooconfig.bedrock.yaml

After running the evaluation, view the results with:

promptfoo view

Example Tool: Weather Function

This example uses a simple weather lookup function that takes a location and optionally a temperature unit. The example illustrates how different providers handle the same function definition with different syntaxes.

External tools can also be loaded from separate files, as demonstrated with external_tools.yaml.

Anthropic Strict Mode

The Anthropic provider includes an example with strict: true enabled, which uses Anthropic's structured outputs feature to guarantee that tool parameters exactly match your schema. This is useful for:

  • Building reliable agentic workflows
  • Ensuring type-safe function calls
  • Production systems that require guaranteed schema conformance

When strict: true is enabled, Claude will always return tool inputs that strictly follow your input_schema, with no type mismatches or missing required fields. See the Anthropic structured outputs example for more details.

Finish Reason Assertions

This example also demonstrates the use of finish-reason assertions to validate why a model stopped generating:

  • tool_calls: Verifies the model stopped to make a function/tool call (e.g., weather lookup for cities)

The example shows that when models are asked about weather in real cities (Boston, New York, Paris), they correctly stop generation to make tool calls, resulting in a tool_calls finish reason. This helps ensure your models are using tools appropriately when they should be.

FAQ

Common questions

Discussion

Questions & comments · 0

Sign In Sign in to leave a comment.