Better semantic reporting of what goose is doing
Please explain the motivation behind the feature request. When goose is calling its developer tools we don't do a great job showing what it is actually doing. it either says command, path or it running shell script, possibly other things.
proposal in the server, annotate each tool with what it is doing and show that. in some cases this can be deduced directly from the command (reading file x), and in some cases we should change the tool definition so the llm can fill in this field
/cc @alexhancock
should this be in server, or core crate - as CLI will need it too?
I'd imagine we'd build this into the agent loop. that already sends out messages before it starts a tool; we can just annotate those with what to display which we could first just take from the desktop if statement and then later have it be produced by the LLM directly
Yes - want to do this one. Will begin when https://github.com/block/goose/issues/3578 is done,
Got away from this task, but could look again at it if we're still interested.
@katzdave what is the current state of generalized notifications through the API to the client?
So we have SystemNotification with 2 types:
Inline: I think this is a nice abstraction; just embeds messages in the chat stream that are visible to the user but not agent. Thinking: Might need some more thought since the client operates mostly on defined states, and maybe the message stream isn't the best way.
But I do think the thinking text in the UI is a nice place to communicate what the agent is doing, and is worth pursuing. We should get aligned with @zanesq on what a good mechanism would be. Also curious if you have any thoughts on how to get information from tools about what they are doing; is there anything in the mcp spec?
we could add a tool for this tell-the-user-what-you-are-doing(string) and then ask goose that when it makes a toolcall, in general it should also call the explain tool. and then when that happens we system message that to the client/