Create a tool-call test

This is the reliability drill-down for the tool-call test type. It fails often, almost always on the tool_call_parameters shape (wrong eval type, wrong referenced_tool, bracket paths). A tool test replays your chat_history turns, then checks whether the agent's next action is the expected tool call. For a single agent reply use the LLM-test skill; for a multi-turn role-play use the simulation-test skill.

Host https://api.elevenlabs.io, header xi-api-key: $API_KEY. The engineer supplies $API_KEY, $AGENT_ID, and $BRANCH_ID where relevant.

1. Gather context first

You cannot write a correct referenced_tool without the target tool's real id and type, and you cannot write a realistic chat_history without knowing what the agent is supposed to do. Read these first, in parallel where independent:

• List the agent's tools (GET /v1/convai/tools, or the tool ids from conversation_config.agent.prompt.tool_ids on the agent config, then GET /v1/convai/tools/{tool_id}). Required: this is where you get the target tool's id and type (webhook, client, code, or system). referenced_tool needs both, and the type must match the tool's real executor type or creation fails.
• GET /v1/convai/agents/$AGENT_ID?branch_id=$BRANCH_ID - the prompt and first message, so the chat_history is a plausible lead-up to the tool call, and the base tool_ids so you know the tool is available to the agent. For a workflow agent, the workflow in this config tells you whether the tool is scoped to a node via additional_tool_ids.
• List existing tests to reuse the naming scheme and avoid a duplicate.

If grounding the test in a real call, read that conversation (GET /v1/convai/conversations/{conversation_id}) to lift the exact tool name and parameters the agent actually used. Conversation reads carry customer PII; do not copy them elsewhere and respect zero-retention-mode accounts.

2. Create the test