Interactive tool cards beyond WispAsk

[zmanian]

Context

The WispAsk MCP tool (#19) introduced a pattern where Claude blocks waiting for user input, and Wisp renders an interactive card inline in the chat. This pattern is more general than just questions -- it could apply to any tool where Claude would benefit from pausing and getting user confirmation or selection before proceeding.

The general pattern

1. MCP tool call arrives via the NDJSON stream
2. Wisp detects the tool name and renders a specialized inline card (not just a collapsible step row)
3. User interacts with the card (tap option, type response, approve/reject)
4. Wisp writes the response to a file on the Sprite
5. MCP server detects the response file and unblocks Claude

The plumbing is already generic -- stream parsing, tool use/result linking, and file upload all work for any tool name. New interactive tools just need a new MCP tool, a card view, and a response callback.

Ideas for new interactive tool cards

1. Write/Edit approval

Instead of Claude writing files with --dangerously-skip-permissions, an MCP tool could present proposed changes as an inline diff preview and let the user approve, reject, or request modifications before the write happens. Especially valuable for destructive edits.

2. Bash confirmation

For commands that look risky (rm -rf, git push --force, database mutations), present the command inline and wait for user approval. Wisp becomes the permission gate instead of --dangerously-skip-permissions.

3. Branch/commit selection

When Claude needs to pick between branches, commits, or PRs, present them as tappable options rather than Claude guessing or asking via text.

4. File picker

When Claude needs to choose which file to work on and there are multiple candidates (e.g., after a Glob), present results as selectable options inline.

5. Test result triage

After running tests, present failures as interactive cards where the user can say "fix this one", "skip -- expected failure", or "stop and let me look at this."

Architecture notes

Each new interactive tool would follow the same structure as WispAsk:

• A Python MCP server script (or extend the existing one with multiple tools)
• A SwiftUI card view that extracts structured fields from card.input
• A special-case branch in AssistantMessageView for the tool name
• A response submission method in ChatViewModel
• File-based communication via the Sprites filesystem API

The MCP server could be extended to handle multiple tools in a single process, reducing setup overhead.

[mcintyre94]

This is a fun idea, would make it work more like claude code interactive where you can toggle whether it should ask you before editing things. In an "ask me first" mode, it could basically present tool calls to you the way Claude Code does interactively.

I think you're right that it could basically share the same server logic for all of them - the server is just suspend and wait, with Wisp UI having the per-tool logic.

I haven't played much with custom tools in Claude, so I'm curious how well it would work for some of these. I was surprised how well swapping out the ask tool worked. Presumably for the first 2 we could do the same, disallow the write/edit/bash/etc tools and present a replacement. I think that'd probably work reasonably well, and it'd use the replacements when it'd usually use the normal ones. But for things that it doesn't have default tools for - branch select, file picker, test triage, I wonder how well it'd pick them up and use them when it needs to do those things. It could be quite annoying if usage of those tools is inconsistent, since we can't disallow it the alternative in the same way.