fix: improve tool call parameters rendering

[eneufeld]

What it does

Change the rendering of the tool call parameters to:

• show no key if only one parameter is passed
• show ... if there are multiple parameters passed
• improve collapse/expand rendering for parameters

fixes #16029

How to test

Use any agent and let it call a function which expects a parameter.

Follow-ups

Breaking changes

• This PR introduces breaking changes and requires careful review. If yes, the breaking changes section in the changelog has been updated.

Attribution

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines
• User-facing text is internationalized using the nls service (for details, please see the Internationalization/Localization section in the Coding Guidelines)

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines

[ndoschek]

Thanks, Eugen! The condensed argument logic is a nice improvement and reads well 👍

However, I'm not convinced about the nested <details> approach for displaying the arguments. Having a collapsible <details> inside the <summary> of the outer <details> (which expands to show the tool result) creates two independent expand/collapse interactions stacked together. This can be confusing: clicking the arguments area may also toggle the outer details, and users are unlikely to expect two separate levels of expansion IMO.

I would suggest a simpler approach:

1. Show the entire arguments inline in the tool call summary as plain text.
2. Add a tooltip on tool hover that shows the full arguments (tool name plus all argument key–value pairs, pretty-printed). We already use the HoverService the prompt variant badge in the chat UI for example which also allows more complex tooltip content.

This could look like this for example:

This example uses a JSON code block for the arguments inside a markdown string for the tooltip.

Overall, this keeps the summary clean and easy to scan, while still making full argument details available on hover, without adding extra interaction complexity to the expand/collapse behavior for the tool result.

WDYT?

[sdirix]

I agree, nested collapsibles should be avoided. As the arguments are always objects we could also specialize the rendering of it a bit. So it looks less like a JSON and more like a list of attributes.

In many cases we could also just not render the ... in the title but immediately render the most important part. So for the example of Nina, this could be

Ran findFilesbyPattern (**/*.md ...)

With the ... indicating that this was not the full argument.

---

This can't be solved generically. Each tool needs to have something like "getArgumentsShortLabel" which then returns something like { label: string, hasMore: boolean}. The default implementation for a tool which does not provide that (e.g. MCP) could be the implementation of the current PR.

This would improve readability by a lot, often not even requiring the user to expand to see what happened.

[ndoschek]

Thank you for the updates Eugen, this works much better now 👍

Just one minor thing: The display differs when we have one vs multiple arguments. I would tend to show only the value also for a single argument, for example ...FileList(.theia), as we have the entire object on hover now anyway, WDYT?

[ndoschek]

Thank you @eneufeld for the updates! LGTM and works great!
I tested with several different functions and arguments and this is a great UX improvement and feels very intuitive now!

[JonasHelming]

@eneufeld @ndoschek
This does not look good to me:

[JonasHelming]

Also I am not sure about the hover in general. If the mouse is above the chat it sometimes "flows" under the mouse pointer and opens arbitrary hovers then. Finally, we lost the ability to see the actual content of a tool call completly.

Sorry for raising these issues, In general i like this improvement a lot and I think is was long outstanding!

[eneufeld]

@JonasHelming who checks writeFile content ;-)

Seriously, good catch.
Can you explain what you mean by Finally, we lost the ability to see the actual content of a tool call completly.
I will open a follow up, maybe you can explain there so we can fix.

[eneufeld]

@JonasHelming Thank you for raising the issues, can you elaborate here: #16988