fix: serialize standard context tools

[sysradium]

Guard tool extraction so that when context tools expose a standard_tools list we include both their raw form and a sanitized serialized version with name/description tuples; fall back to the previous behavior otherwise.

The same pattern is already being used in llm_setup branch.

Currently it leads to this issue:

app-1  | 2026-03-24 16:08:46.470 | DEBUG    | pipecat.pipeline.task:_wait_for_pipeline_start:748 - PipelineTask#0: StartFrame#0 reached the end of the pipeline, pipeline is now
ready.
app-1  | WARNING:root:Error extracting context tools: Object of type ToolsSchema is not JSON serializable
app-1  | ERROR:root:Error in OpenAI Realtime tracing (continuing without tracing): object of type 'ToolsSchema' has no len()
app-1  | 2026-03-24 16:08:46.478 | DEBUG    | pipecat.adapters.base_llm_adapter:from_standard_tools:127 - Retrieving the tools using the adapter: <class
'pipecat.adapters.services.open_ai_realtime_adapter.OpenAIRealtimeLLMAdapter'>
app-1  | 2026-03-24 16:08:46.599 | DEBUG    | pipecat.services.openai.realtime.llm:_create_response:1034 - Setting up conversation on OpenAI Realtime LLM service with initial
messages

[codecov]

Codecov Report

❌ Patch coverage is 0% with 10 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/pipecat/utils/tracing/service_decorators.py	0.00%	10 Missing ⚠️

Files with missing lines	Coverage Δ
src/pipecat/utils/tracing/service_decorators.py	12.83% <0.00%> (-0.20%)	⬇️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sysradium]

Still relevant:

[sysradium]

@markbackman any possibility to look into this? As I have to maintain a fork of pipcat to be able to see langsmith traces :(

[markbackman]

Could we use the adapter here instead of manually rebuilding the tool list?

In this path context_tools can be a ToolsSchema, and OpenAI Realtime ultimately sends tools via the adapter’s provider-format conversion. This manual serialization only looks at standard_tools, so it can miss custom_tools for AdapterType.OPENAI and may drift from the actual payload sent to the provider.

Something like starting from self.get_llm_adapter().from_standard_tools(context_tools) would keep tracing aligned with the real OpenAI Realtime tool format, including custom/provider-specific tools, and avoid adding provider-specific serialization logic in tracing.

[sysradium]

Hey @markbackman,
Many thanks for the comments. Would something of this sort work?
I added a defensive getattr in there still. I think it should work.

[sysradium]

@markbackman bump