What is the reasoning for having limited views for different span kinds for example TOOL span contains similar features to LLM spans but is just a lot more limited. I am currently looking into instrumenting Mistral OCR and I feel like I am forced to make calling OCR an LLM span so that I can leverage displaying images
It seems likely that Phoenix intentionally limits the attributes and UI features available for certain span kinds (like TOOL) to encourage semantic clarity and to simplify trace visualization. TOOL spans are designed to represent calls to external tools (e.g., calculators, APIs), while LLM spans are for language model invocations, and the UI is optimized to display attributes relevant to each kind. As a result, features like image display or message threading may only be fully supported for LLM spans, not TOOL spans, even if the underlying data is similar. This design is reflected in the documentation and span kind definitions, which emphasize using the correct span kind for each operation type, and in user reports noting that TOOL spans have more limited display options compared to LLM spans, especially for complex outputs like images or structured messages (docs/tracing/llm-traces/what-are-traces.md, OpenInference spec, Slack discussion).If you want to leverage richer UI features (like image display) for OCR, you may need to use the LLM span kind, even if the operation is technically a tool call. This is a known limitation, and some users have worked around it by instrumenting such calls as LLM spans to get the desired UI behavior (Slack discussion). Would you like more detail on how to structure your spans or on possible workarounds?Sources: - docs/tracing/llm-traces/what-are-traces.md - OpenInference spec - Slack discussion
馃挕聽Hint: Mention RunLLM in the thread for followups.
