architect-troubleshoot-tool-errors

Diagnose a misbehaving tool by reading the exact error first, then matching the failure pattern. All API calls use xi-api-key: $API_KEY against https://api.elevenlabs.io.

Check this FIRST on any schema_mismatch from a webhook or client tool

Every parameter/property object must set EXACTLY ONE value source: a non-empty description (the LLM fills it), OR dynamic_variable, OR a non-empty constant_value, OR is_system_provided: true.

• ZERO sources is invalid. {"type":"string","constant_value":""} with no description is rejected; an empty-string constant_value does NOT count as a constant. Give the field a real description.
• TWO OR MORE sources is invalid.
• This applies to parameters, request_body_schema.properties, path_params_schema, query_params_schema, and request_headers alike.

If the error names type or constant_value on a property, this rule is almost always the cause. Fix the value source before investigating anything else.

Do not repeat these mistakes

1. Never guess a tool's config schema or hand-build config JSON blind. Read the tool's actual saved config first with GET /v1/convai/tools/{tool_id} and change from there.
2. Read the actual error before theorizing. For a runtime failure, read the conversation where it happened with GET /v1/convai/conversations/{conversation_id} and find the failing tool call and its error verbatim; for a save failure, ask the user to quote the exact error text.
3. State tool field names, defaults, and limits from the current config you read, not from memory; they change.

Match the failure pattern