diff --git a/specs/GH10740/product.md b/specs/GH10740/product.md new file mode 100644 index 0000000000..5495915fc1 --- /dev/null +++ b/specs/GH10740/product.md @@ -0,0 +1,68 @@ +# MCP Prompts Capability — Product Spec +GitHub issue: https://github.com/warpdotdev/warp/issues/10740 +Figma: none provided. The argument-entry UI must reuse the existing templatable MCP installation variable input pattern rather than introducing a new design surface. +## Summary +Warp should treat MCP server prompt templates as a first-class MCP capability alongside tools and resources. When an MCP server advertises the `prompts` capability during initialization, Warp lists that server's prompts, makes them discoverable in the slash-command menu, lets the user invoke a prompt by selecting or typing its generated slash command, collects any declared arguments, calls `prompts/get`, and submits the rendered prompt into Agent Mode. +The desired outcome is that prompt-focused MCP servers no longer appear connected but empty in Warp. Users should be able to discover and use MCP prompts without manually copying prompt names or leaving the terminal input flow. +## Problem +Warp currently connects to MCP servers and lists `tools` and `resources` when those capabilities are advertised, but it does not query or surface `prompts`. Prompt-only servers can therefore look broken in Warp: they can be connected and useful according to the MCP protocol, but the user sees no available MCP surface in the app. +This also creates an inconsistent MCP mental model. Users can use MCP tools through Agent Mode and MCP resources through resource reads, while MCP prompt templates are invisible even though they are part of the same capability negotiation model. +## Goals +- Query `prompts/list` only for MCP servers that advertise the `prompts` capability during initialization. +- Store prompt metadata on active MCP server state so prompt discovery can reuse the same connected-server lifecycle as tools and resources. +- Surface active MCP prompts in the slash-command menu as generated commands using the `/mcp..` naming family. +- Allow users to invoke an MCP prompt by selecting it from the slash menu or typing the generated command exactly. +- For prompts with declared arguments, show a lightweight argument form using the existing templatable MCP installation variable input affordance, including required/optional handling. +- Call `prompts/get` with the populated argument values and submit the returned prompt text to Agent Mode as a user-initiated prompt. +- Preserve existing AI and MCP safety controls: no prompt should execute when AI is disabled, when the source MCP server is not currently active, or in a way that bypasses normal Agent Mode permissions. +- Fail soft when listing prompts fails, matching the existing tools/resources behavior: the MCP server should still start and its other capabilities should remain usable. +## Non-goals +- Building a new prompt-template designer or new modal design system for MCP prompt arguments. +- Editing, saving, syncing, or sharing MCP prompts as Warp Drive prompts. +- Adding a new Settings page for MCP prompts. +- Changing MCP tool-call, resource-read, or permission semantics. +- Automatically invoking MCP prompts without a user selecting or typing a generated command. +- Supporting arbitrary rich prompt message rendering beyond what Agent Mode can accept as text in the initial implementation. Rich content support can be added later if needed. +- Changing prompt data on the MCP server. Warp only lists prompts and calls `prompts/get`; it does not create, update, or delete prompts. +## User experience +1. When a user has one or more running MCP servers that advertise prompts, opening the slash-command menu includes MCP prompt entries in addition to built-in slash commands, skills, and saved prompts. +2. Each MCP prompt entry displays a generated command name in the format `/mcp..`. The entry description uses the prompt description from `prompts/list` when present. If no description is present, the entry should indicate the server that provides it rather than showing an empty row. +3. Server and prompt slugs are deterministic and stable for the active server session. They should be lowercased, whitespace-normalized, and safe to type in a slash command. If two active prompts would produce the same command name, Warp keeps both discoverable by appending a short deterministic disambiguator to the later command names and showing the original server/prompt names in the row description. +4. MCP prompt entries are grouped with prompt-like items in Cloud Mode V2's slash menu. Existing saved prompts remain visible and continue to behave as saved prompts. +5. MCP prompt entries are hidden when AI is globally disabled. File-based MCP prompts are visible only when their backing file-based MCP server is active under the existing file-based MCP enablement and working-directory scoping behavior. +6. MCP prompt entries update as servers start, stop, reconnect, or change active scope. A stopped server's prompts are removed from the menu. A restarted server's prompts reappear after the next successful `prompts/list` call. +7. Selecting an MCP prompt with no declared arguments immediately invokes it. Warp calls `prompts/get` for the selected server/prompt, converts the returned text prompt messages into the Agent Mode prompt body, and sends that text as a user-initiated Agent Mode prompt. +8. Selecting an MCP prompt with one or more declared arguments opens an argument-entry form before calling `prompts/get`. The form reuses the existing templatable MCP installation variable input pattern: a compact modal with one input per variable, Escape to cancel, and Enter or the primary action button to submit. +9. Argument fields display the MCP argument name and, when present, its description. Required arguments are visually distinguishable and must be filled before submission. Optional arguments may be left blank; blank optional arguments are omitted from the `prompts/get` arguments map unless the MCP SDK requires explicit empty strings. +10. If argument submission fails validation, Warp keeps the form open and focuses the first invalid required field. No request is sent to the MCP server until local validation passes. +11. If `prompts/get` succeeds, Warp closes the argument form, clears the generated slash command from the input buffer if it was typed there, and submits the rendered prompt into Agent Mode. If no Agent conversation is active, Warp enters Agent Mode and starts a new conversation with the rendered prompt. If a conversation is active, Warp submits the rendered prompt as a follow-up using the same user-initiated path as typed prompts. +12. If the selected MCP server disconnects before invocation completes, Warp shows an error toast and does not submit a partial prompt. If reconnection support can transparently reconnect the server, Warp may retry once using the existing reconnecting peer behavior before showing the error. +13. If `prompts/get` returns an MCP error, Warp shows a concise error toast that names the prompt and server. The prompt is not submitted to Agent Mode. +14. If `prompts/get` returns only unsupported non-text prompt content, Warp shows an unsupported-content error and does not submit an empty prompt. If it returns both text and unsupported content, Warp submits the supported text and includes clear placeholder text for omitted content only if that is less confusing than failing the whole invocation. +15. MCP prompt text is treated as user-selected prompt content for the agent, not as trusted application instructions. It must not bypass Agent Mode permission prompts, MCP tool permissions, command allow/deny lists, or any other execution-profile policy. +16. Telemetry may record non-content metadata such as command source, server installation id, prompt name, whether arguments were present, and success/failure. Telemetry must not include argument values or rendered prompt content. +17. Prompt listing failures are not user-blocking at startup. If `prompts/list` fails, the server still appears running and any listed tools/resources remain available. The failure may be logged in MCP logs and omitted from the slash menu. +18. Prompt invocation is explicit. Merely opening the slash menu or filtering MCP prompt entries must not call `prompts/get`. +## Success criteria +- Prompt-only MCP servers that advertise `prompts` no longer appear functionally empty in Warp; their prompts can be found from the slash menu after the server connects. +- A user can type `/mcp` and see matching MCP prompt entries for active prompt-capable servers. +- A user can select a prompt with no arguments and see the rendered prompt submitted to Agent Mode without manually copying or editing it. +- A user can select a prompt with required arguments, fill them in through the existing MCP variable input-style form, and submit a `prompts/get` request with the expected argument map. +- Required arguments cannot be submitted blank; optional arguments can be omitted. +- Prompt entries disappear when their server stops and reappear when it reconnects and prompt listing succeeds. +- Servers that advertise tools/resources but not prompts do not receive `prompts/list` calls. +- Servers that advertise prompts but fail `prompts/list` still start and remain usable for other capabilities. +- AI-disabled users do not see or invoke MCP prompt entries. +- Prompt invocation does not leak argument values or prompt text through telemetry. +## Validation +- Unit tests cover capability gating for tools, resources, and prompts independently across all advertised-capability combinations. +- Unit tests cover `query_prompts_for` happy path, skipped path, empty-list path, and fail-soft MCP/transport errors. +- Unit tests cover generated slash-command names, duplicate disambiguation, filtering, and parsing of typed MCP prompt commands. +- Unit tests cover argument validation for required and optional `PromptArgument` values. +- Unit tests or model tests cover dynamic menu updates when MCP server state changes. +- An integration or manual validation flow uses a test MCP server that advertises prompts only, confirms prompt entries appear in the slash menu, invokes a no-argument prompt, invokes a required-argument prompt, and verifies the rendered text reaches Agent Mode. +- Manual validation confirms a prompt-capable server with a failing `prompts/list` still starts and exposes any tools/resources it lists successfully. +## Open questions +- Should mixed text and non-text prompt content submit best-effort text with placeholders or fail the invocation until rich prompt content support is designed? The initial spec prefers avoiding empty/ambiguous submissions, but implementation should choose the least surprising behavior once rmcp's returned content shapes are inspected. +- Should MCP prompt invocations be included in the same analytics bucket as saved prompts or receive a distinct slash-command accepted detail? The product requirement is metadata-only telemetry; the exact event taxonomy can be decided during implementation. +- Should the generated command name include the raw prompt name when it is already slash-safe, or always use the normalized slug for consistency? The spec requires deterministic slash-safe names either way. diff --git a/specs/GH10740/tech.md b/specs/GH10740/tech.md new file mode 100644 index 0000000000..b99f5962d8 --- /dev/null +++ b/specs/GH10740/tech.md @@ -0,0 +1,132 @@ +# MCP Prompts Capability — Tech Spec +Product spec: `specs/GH10740/product.md` +GitHub issue: https://github.com/warpdotdev/warp/issues/10740 +## Problem +Warp's MCP startup path already negotiates server capabilities and lists tools/resources, but it omits the `prompts` capability. The implementation needs to add prompts to the MCP active-server model, expose active prompt metadata through the slash-command data sources, add an invocation path that calls `prompts/get`, and submit the rendered prompt into Agent Mode without bypassing existing AI/MCP safety gates. +## Relevant code +- `app/src/ai/mcp/templatable_manager/utils.rs:9` — capability-gated helper pattern for listing resources and tools with fail-soft behavior. +- `app/src/ai/mcp/templatable_manager/utils_tests.rs:11` — unit tests that sweep tool/resource capability combinations and list-helper failures. +- `app/src/ai/mcp/templatable_manager.rs:120` — `TemplatableMCPServerInfo`, currently storing `resources` and `tools` for a connected server. +- `app/src/ai/mcp/templatable_manager.rs:224` — manager iterators/lookups for active resources and tools. +- `app/src/ai/mcp/templatable_manager/native.rs:839` — successful spawn handler inserts `TemplatableMCPServerInfo` into `active_servers` and emits state changes. +- `app/src/ai/mcp/templatable_manager/native.rs:1909` — `spawn_server` reads peer capabilities and lists resources/tools before constructing server info. +- `app/src/ai/mcp/reconnecting_peer.rs:116` — reconnecting request wrapper used for MCP tool/resource calls and the right pattern for `prompts/get` retry behavior. +- `app/src/ai/blocklist/action_model/execute/call_mcp_tool.rs:107` — MCP tool execution path that resolves the active server and calls through `ReconnectingPeer`. +- `app/src/ai/blocklist/action_model/execute/read_mcp_resource.rs:91` — MCP resource execution path that resolves active resources and calls through `ReconnectingPeer`. +- `app/src/terminal/input/slash_commands/data_source/mod.rs:226` — slash-command data source recomputes active static commands from session, AI, and command-context gates. +- `app/src/terminal/input/slash_commands/data_source/mod.rs:426` — `SyncDataSource` query implementation for static commands and skills. +- `app/src/terminal/input/slash_commands/data_source/saved_prompts.rs:21` — async saved-prompt source that returns `AcceptSlashCommandOrSavedPrompt` menu actions. +- `app/src/terminal/input/slash_commands/data_source/zero_state.rs:124` — Cloud Mode V2 zero-state adds saved prompt rows under the prompt section. +- `app/src/terminal/input/slash_commands/view.rs:46` — slash menu events and accepted item variants for static commands, saved prompts, and skills. +- `app/src/terminal/input/slash_commands/mod.rs:65` — `AcceptSlashCommandOrSavedPrompt`, the action enum shared by slash-menu data sources. +- `app/src/terminal/input/slash_commands/mod.rs:312` — selected saved prompts are dispatched from the slash-menu event handler. +- `app/src/terminal/input/slash_command_model.rs:416` — parsing for typed slash commands based on the active command set. +- `app/src/settings_view/mcp_servers/installation_modal.rs:48` — existing templatable MCP variable input pattern to reuse for MCP prompt arguments. +- `app/src/terminal/input.rs:13072` — queued/typed prompts are routed into existing slash, skill, or Agent Mode submission paths. +- `app/src/terminal/input.rs:13367` — normal Agent Mode prompt submission enters Agent Mode or sends a follow-up in the current conversation. +## Current state +`TemplatableMCPServerManager::spawn_server` connects to an MCP server, reads `server_info.capabilities`, then calls `query_resources_for(... service.list_all_resources())` and `query_tools_for(... service.list_all_tools())`. The returned metadata is stored in `TemplatableMCPServerInfo` and exposed through manager iterators/lookups. The manager emits state changes after a server becomes running or stops, and consumers can subscribe to those model events. +The slash-command menu is not limited to compile-time static commands. It mixes a sync source for static commands/skills, async saved-prompt results, and a zero-state source. Menu selection is represented by `AcceptSlashCommandOrSavedPrompt`, which currently supports static commands, saved prompts, and skills. Typed slash command parsing only considers active `StaticCommand` values, so dynamic MCP prompt commands need a parallel dynamic parse path rather than being added to the static registry. +The existing templatable MCP installation modal already renders one variable input per `TemplateVariable`, supports text inputs/dropdowns, Enter submission, and Escape cancellation. The MCP prompt argument UI should reuse this component pattern, but it needs prompt-specific required/optional validation because `PromptArgument` has different semantics from installation template variables. +## Proposed changes +### 1. Add prompt listing to MCP startup +Extend `app/src/ai/mcp/templatable_manager/utils.rs` with: +- `should_query_prompts(capabilities: Option<&rmcp::model::ServerCapabilities>) -> bool`, returning true only when `capabilities.prompts.is_some()`. +- `query_prompts_for`, mirroring `query_resources_for` and `query_tools_for`, returning `Vec` and failing soft by logging and returning an empty vector on `rmcp::ServiceError`. +Update `utils_tests.rs` to make the helper `caps(...)` cover tools, resources, and prompts. Keep the independence sweep explicit: each capability should be queried iff that capability is advertised, regardless of the other two. Add prompt-specific tests for skipped/no server info, happy path, empty list, transport error, MCP error, and exactly-once list invocation. +In `native.rs`, import `query_prompts_for` and call it in `spawn_server` after capabilities are available: +- `let prompts = query_prompts_for(capabilities, &server_name, || service.list_all_prompts()).await;` +- Store `prompts` alongside `resources` and `tools` in the returned `TemplatableMCPServerInfo`. +This preserves the current startup behavior: prompt listing cannot make the server fail to start, and servers without the prompt capability do not receive a prompt-list request. +### 2. Store and expose active prompt metadata +Extend `TemplatableMCPServerInfo` in `templatable_manager.rs` with a `prompts: Vec` field and a `prompts(&self) -> &Vec` getter. +Add manager-level helpers consistent with the existing resource/tool API: +- `prompts(&self) -> impl Iterator` for all active prompts. +- `prompts_for_server(&self, uuid: Uuid) -> Vec` for a single server. +- `server_with_prompt_name(&self, installation_id: Uuid, prompt_name: &str) -> Option` for invocation. +- Optionally `active_prompt_entries(...)` returning `(installation_id, server_name, prompt)` tuples if that makes the slash data source simpler and avoids exposing `active_servers` internals. +The implementation should include prompts from all active server categories already represented by `active_servers`: installed templatable servers, file-based servers that are currently in scope/running, and CLI-spawned ephemeral servers. No separate prompt cache is required in persistence for the first implementation; prompt metadata is runtime state tied to a live server connection. +### 3. Add `prompts/get` request support +Extend `app/src/ai/mcp/reconnecting_peer.rs` with: +- `pub async fn get_prompt(&self, params: rmcp::model::GetPromptRequestParams) -> Result` using the same `with_reconnect_retry` wrapper as `call_tool` and `read_resource`. +Add a small MCP prompt invocation helper, either under `app/src/ai/mcp/templatable_manager/` or in a new `app/src/ai/blocklist/action_model/execute/get_mcp_prompt.rs` if routing through the action model is preferable. The helper should: +- Resolve the selected `installation_id` and `prompt_name` against active manager state at invocation time. +- Build `GetPromptRequestParams` with the prompt name and argument map after local validation. +- Call `ReconnectingPeer::get_prompt`. +- Convert the returned prompt messages to a single text prompt body for Agent Mode. +For the first implementation, conversion should support text content directly and handle unsupported non-text content according to the product spec: do not submit an empty prompt, and avoid silently dropping all returned content. Keep the conversion logic unit-testable separately from UI code. +### 4. Add a dynamic MCP prompt slash-menu source +Create a new data-source module, for example `app/src/terminal/input/slash_commands/data_source/mcp_prompts.rs`, with a snapshot of active prompt entries. It can be a sync source because active prompt metadata is already in memory. +Each entry should carry: +- `installation_id: Uuid` +- `server_name: String` +- `prompt_name: String` +- `prompt_description: Option` +- generated `command_name: String` +- argument metadata copied from `rmcp::model::Prompt` +Generate command names as `/mcp..`. Slug generation should be deterministic, slash-safe, and covered by tests. Keep a per-snapshot map to detect generated-name collisions; append a short stable suffix derived from installation id and prompt name when needed. +Extend `AcceptSlashCommandOrSavedPrompt` with an MCP prompt variant, for example: +- `MCPPrompt { installation_id: Uuid, prompt_name: String, command_name: String }` +Add `InlineItem::from_mcp_prompt(...)` that uses a prompt/dataflow icon, monospace command title, description, match highlighting, and compact-layout support. +Wire this source into both slash menu mixers in `view.rs` and `cloud_mode_v2_view.rs`. For Cloud Mode V2 zero state, either add active MCP prompts in `zero_state.rs` near saved prompts or make the MCP prompt source run in zero state when `is_cloud_mode_v2` is true. `Section::for_action` should classify MCP prompts as `Section::Prompts` so they appear with saved prompts. +### 5. Keep active prompt results fresh +Subscribe `SlashCommandDataSource` or the MCP prompt source owner to `TemplatableMCPServerManager` events. At minimum, trigger a menu query refresh on: +- `TemplatableMCPServerManagerEvent::StateChanged` for Running/NotRunning/Failed transitions. +- `ServerInstallationAdded` and `ServerInstallationDeleted`. +- `TemplatableMCPServersUpdated`. +If needed, introduce a broader `MCPPromptEntriesUpdated` or reuse `UpdatedActiveCommands` to tell existing menu views to rerun their current query. Avoid overloading static `active_commands_by_id` with dynamic prompts; prompt entries are not static commands and should not be stored in `COMMAND_REGISTRY`. +### 6. Parse typed MCP prompt commands +Extend typed slash-command detection so a buffer matching a generated MCP prompt command returns a detected dynamic prompt state. There are two reasonable implementation shapes: +1. Add `SlashCommandEntryState::MCPPromptCommand(DetectedMCPPromptCommand)` and route Enter/Cmd-Enter through a new `execute_mcp_prompt_command` method. +2. Keep `SlashCommandEntryState` focused on static/skill commands and have `Input::maybe_handle_enter_for_slash_command` ask the MCP prompt data source for an exact command match before falling back to plain AI input. +Prefer the first approach because it preserves syntax highlighting, hides the menu after a detected command, and mirrors the skill-command path. The detected state should include the selected installation id, prompt name, generated command name, and no freeform trailing argument; prompt arguments are collected by the form rather than parsed from shell-like text. +### 7. Implement argument collection UI with existing modal patterns +Add a prompt-specific modal/body that reuses the visual and behavioral pattern from `InstallationModalBody` rather than changing the installation modal itself. Reusing shared helper components is fine, but avoid coupling prompt invocation to installation data types. +The prompt argument model should be derived from `rmcp::model::PromptArgument`: +- name/key +- description/help text +- required flag +- optional default if rmcp exposes one in the model version +The form should create text inputs in prompt argument order. Dropdowns are only needed if MCP/rmcp exposes allowed values for prompt args; otherwise all prompt args can be text inputs. Required blank inputs block submission and focus the first invalid field. Escape cancels without calling `prompts/get`. +On submit, build a `HashMap` or the exact rmcp argument map type expected by `GetPromptRequestParams`. Omit blank optional values unless rmcp requires explicit empty values. +### 8. Dispatch rendered prompts into Agent Mode +Add an input-level method such as `Input::invoke_mcp_prompt(...)` or `Input::submit_rendered_mcp_prompt(...)` that receives the rendered text from the async invocation helper and sends it through the existing user-initiated Agent Mode submission path: +- If Agent View is inactive, emit `Event::EnterAgentView { initial_prompt: Some(rendered_prompt), origin: AgentViewEntryOrigin::SlashCommand { trigger } }`. +- If an Agent conversation is active, call the same controller path used by `submit_ai_query` for `send_user_query_in_conversation` and emit `Event::ExecuteAIQuery`. +- If the queue-next-prompt setting is active and the current conversation is in progress, use the same queuing behavior as typed prompts rather than bypassing the queue. +Do not introduce a new AI action type unless implementation discovers that agent-visible structured results are required. MCP prompt invocation is user-initiated prompt composition, not an agent-requested tool action, so it can live in input/slash-command handling rather than the blocklist action queue. +### 9. Telemetry and privacy +Extend `SlashCommandAcceptedDetails` or add a dedicated metadata event for MCP prompt acceptance. Include only non-content metadata: generated command family, installation id or redacted stable id, prompt name, has_arguments, argument_count, success/failure category, and whether the command was accepted in Agent View. Do not log argument values or rendered prompt content. +The MCP log may include protocol errors but should not log prompt argument values beyond what rmcp/transport logging already captures. If the invocation helper logs failures, keep messages to server/prompt names and error categories. +## End-to-end flow +1. A user starts or scopes into an MCP server. +2. `spawn_server` connects, reads capabilities, and calls `query_prompts_for` only if prompts are advertised. +3. The resulting prompts are stored in `TemplatableMCPServerInfo` under the active server's installation UUID. +4. The slash menu opens or reruns its query. The MCP prompt data source snapshots active prompt entries and emits menu items named `/mcp..`. +5. The user selects or types an MCP prompt command. +6. If arguments are declared, Warp opens the prompt-argument modal and validates required inputs. If no arguments are declared, Warp proceeds immediately. +7. Warp resolves the active server again, calls `prompts/get` through `ReconnectingPeer`, and converts the result to text. +8. Warp submits the rendered text to Agent Mode as a user prompt. Existing Agent Mode permission checks continue to apply to whatever actions the agent later requests. +## Risks and mitigations +- **Prompt command name collisions:** Use deterministic slugs plus short suffixes for duplicate generated names. Keep original server/prompt names in descriptions so users can distinguish entries. +- **Prompt content may contain prompt injection:** Treat returned content as user-selected prompt text, never as app instructions. Normal Agent Mode permissions remain authoritative. +- **Non-text prompt content:** Keep conversion logic explicit and tested. Do not silently submit an empty prompt if all returned content is unsupported. +- **Stale active-server state:** Resolve the server and prompt again at invocation time. If the server stopped after the menu snapshot, show an error and do not submit. +- **Startup regressions:** Keep `query_prompts_for` fail-soft so prompt listing cannot prevent server startup or hide tools/resources. +- **MCP file-based scope confusion:** Build prompt entries only from active servers already scoped by the manager. Do not separately scan file-based config files for prompts. +- **Telemetry leakage:** Add tests or code review checks around telemetry payload construction to ensure argument values and rendered prompt text are not included. +## Testing and validation +- Unit test `should_query_prompts` and `query_prompts_for` in `utils_tests.rs` alongside tools/resources. +- Unit test triple-capability independence so tools, resources, and prompts are listed only from their own advertised capability flags. +- Unit test prompt slug generation, command collision disambiguation, exact typed-command parsing, and fuzzy matching. +- Unit test MCP prompt data-source gating when AI is disabled and when no prompt-capable servers are active. +- Unit test prompt argument validation and argument map construction for required, optional, blank, and filled values. +- Unit test prompt result conversion for text-only, mixed text/non-text, and unsupported-only returned messages. +- Add model or UI tests for selecting an MCP prompt menu item and routing it to the argument form or immediate invocation path. +- Add a manual validation MCP server fixture, or extend an existing MCP test fixture, to advertise prompts and respond to `prompts/list` / `prompts/get` so the full flow can be verified locally. +- Run the relevant Rust test targets for `app::ai::mcp::templatable_manager::utils_tests`, slash-command data-source/model tests, and any new prompt invocation tests. +## Follow-ups +- Support richer MCP prompt content if Agent Mode adds first-class handling for images, embedded resources, or multi-message role preservation. +- Consider saved/favorite MCP prompts if users want to pin frequently used server prompts independent of server connection state. +- Consider exposing MCP prompt counts or descriptions in Settings → MCP Servers so prompt-only servers do not look empty outside the slash menu. +- Evaluate whether MCP prompt command names should be customizable if generated names are too long or ambiguous for common servers.