[cli] goose mcp prompt support ideas

[kalvinnchau]

There's a PR at #1323 that adds in basic MCP Prompt support. We're looking for feedback and thoughts on goose-cli mcp prompt support!

This discussion should be focused from a cli perspective with UX to come in a separate discussion.

Current Approach

The PR adds two new slash commands to goose-cli:

• /prompts - List all available prompts by name
• /prompt <name> [--info] [key=value...] - Get prompt info or execute a prompt

Listing Prompts

( O)> /prompts

 everything
  - simple_prompt
  - complex_prompt
 developer
  - unit_test
 fetch
  - fetch

Get Prompt Information

This retrieves description and arguments for a given prompt.

( O)> /prompt fetch --info

 Extension: fetch
 Prompt: fetch

 Fetch a URL and extract its contents as markdown

 Arguments:
  url (required) URL to fetch

( O)> /prompt complex_prompt --info

 Extension: everything
 Prompt: complex_prompt

 A prompt with arguments

 Arguments:
  temperature (required) Temperature setting
  style (optional) Output style

Get/Execute Prompt

After passing in any required arguments in the "key=value" format, the responses are added directly to the agent loop and processed.

( O)> /prompt fetch url="https://block.github.io/goose/docs/guides/updating-goose"
... # output in markdown truncated

## Important Notes

- All your configuration settings will be preserved during the update
- The update will install the latest stable version
- The process is the same as the initial installation, but with the `CONFIGURE=false` flag

## Navigation

This guide appears to be part of a documentation series with:
- Previous section: "Managing Sessions"
- Next section: "Using Goosehints"

Would you like me to help you with anything specific about the update process or explore other aspects of Goose?

Looking for Community Input

• How do the ergonomics/usage of /prompts and /prompt k1=v1 k2=v2 .. feel? What other suggestions or approaches do you think are good?
• Any comparable experiences in other agents using prompts and how they compare?
• What might be missing from the commands above?
  • Would a --verbose or similar option be useful to show what was added to the agent loop?

[EbonyLouis]

Kalvin, this is great, I love it! Here are some thoughts I have:

1. Would filtering be useful? For example, /prompts --extension developer to narrow down available prompts

2. The key=value format is cool, adding tab completion or auto suggestions for argument names, for example, typing /prompt fetch and pressing Tab to suggest url= could make it more user friendly.

   • Or, an interactive mode could guide users through filling in required arguments step by step, instead of needing to enter them all upfront.

3. On the same note, you might already have this covered but if a required argument isn’t provided, returning a detailed error message something like this could help:
   /prompt fetch Error: Missing required argument 'url'. Try '/prompt fetch --info' for details.

4. Would support for piping input be useful? I saw in your PR you had /prompt unit_test source_code="~/stage/unit_test/file.py" language=python, but maybe allowing users to pass the file directly instead of them having to give a file path, like this:
   cat file.py | /prompt unit_test language=python
   could be beneficial

5. I like the --verbose flag deff could be useful for debugging too

6. Adding --dry-run or --preview mode, I know we're adding Goose Modes, but this would let users see what will happen before goose actually runs any commands, making it even easier for them to trust it. For example:
   /prompt fetch url="https://example.com" --dry-run

Okay, I’m done, bye lol

[kalvinnchau]

These are great feedback, thank you!

1. Yes - that's a good idea, for users who have many extensions it would be nice to narrow it down.

2. I really like this one, tab completion support for the parameters is 👍. I think I'd perfer <Tab> completion support over interactive mode, but curious to hear users other thoughts.

3. Ah yes I just didn't show what happens in that case, but here is an example (some error handling cleanup messaging tdb, and adding in help message could be useful)

   ( O)> /prompt unit_test
   
     error: Failed to get prompt: Failed to get prompt: RPC error: code=-32603, message=Invalid parameters: Missing required argument: 'source_code'
   
   ( O)> /prompt unit_test source_code="path"
   
     error: Failed to get prompt: Failed to get prompt: RPC error: code=-32603, message=Invalid parameters: Missing required argument: 'language'

4. In the unit_test case, that's what the structure of the prompt itself asked for - a path to the file + language. In practice I think implementing something like cat file.py | /prompt unit_test language=python would be more complicated than its worth since the we'd then need to know how and when to treat goose's interactive session as a command interpreter down to the shell environment.

5. & 6. Good call out on --dry-run or similar, I'll play around with this.

[cliffhall]

I really like this one, tab completion support for the parameters is 👍. I think I'd perfer completion support over interactive mode, but curious to hear users other thoughts.

@kalvinnchau would the interactive mode you mention be something akin to the goose configure experience, but that at its end would spit out the command line for you to run?

e.g.,

/prompt complex_prompt

┌ complex_prompt
│
◆ Temperature setting
│ 0.5
│
◆ Output style (optional)
│ Markdown
│
└ complex_prompt assembled.

/prompt complex_prompt temperature=0.5 style="Markdown"

I sort of like that as an option as well. Maybe a config flag for tab completion on command line vs interactive experience? For large inputs it might be better than tab completion, not sure, would have to experience it. I like that interactive mode would give you a chance to show the arg descriptions rather than just the arg name. Could be cryptic for some args I imagine.

[kalvinnchau]

@cliffhall We now have prompt support in the cli, and currently with the tab completion approach. Check this PR #1436 for a video of it in action.

I haven't had the opportunity to think more on the interactive approach yet - I could see that being helpful for larger prompts, though I'm curious at how often it would be used. I can imagine first use going through interactive, and then once you've gotten used to using it either just tab style or copy pasting.

[cliffhall]

Would filtering be useful? For example, /prompts --extension developer to narrow down available prompts

@EbonyLouis was talking about the /prompts but it made me think about /prompt and the inevitable collisions of lazily named prompts.

Otherwise, if I type

/prompt weather

And there are these prompts to choose from ...

• my-first-mcp/prompts/weather
• weather-channel-mcp/prompts/weather

... then you suddenly need a way for me to select which one, some interactive mode choice. Which could be good, but might be something you want to automate. Maybe this also needs to have a flag for desired behavior.

We could by bypass the interactive mode choice with an extension specifier on the command line

• /prompt --e my-first-mcp weather or /prompt -extension my-first-mcp weather if I need to specify one of many.
• /prompt weather if I know there's only one weather prompt

[kalvinnchau]

Good catch! Name collisions should have been taken into consideration, this would definitely cause an issue with the current implementation. That'll need to get fixed.

[mikegehard-rise8]

I really like how claude code handles mcp promts and built in slash commands, which seem to be treated the same.

1. I type a / and it starts by listing out all of the commands I have access to, including the built in commands, prompts and any MCP added prompts. The MCP server prompts are prefixed by :.
2. As I type, it starts to filter out non-matching commands.

I agree that some sort of autocomplete for prompt params would be amazing so I don't have to remember them.

The goal is to find and use the prompt as quickly as possible. :-)