example-remote-client/docs/clarifying_questions.md

Clarifying Questions

1. Project Scope & Architecture

• Should this be a single-page React app, or do you prefer a specific build setup (Vite, Create React App, Next.js)?
  • I'm okay with a build step - however I would like to have it statically served - so I'm not interested in the server components / server-side functionality of any of those frameworks.
• Do you want TypeScript throughout, or are you open to JavaScript?
  • TypeScript throughout please
• Any preference for CSS approach (CSS modules, styled-components, Tailwind, etc.)?
  • Preference for Tailwind

2. Multi-Server Connection Management

• How should users add/manage multiple MCP server connections? Through a UI form, config file, or both?
  • UI form. I think that we should have the left hand side of the UI be all about MCP functionality (server statuses, debugging, MCP message trace even) and the right hand side being the chat window. I would like things to be as modular as possible so that we can refactor the UI as needed.
• Should connections be persistent across browser sessions, or reset on each visit?
  • Like the MCP sessions? I think it would be cool to have sessions persist if it's shttp. For SSE that's not an option (as the session technically ends with the SSE connection)
• Do you want a dashboard view showing all connected servers, or focus on the conversational interface?
  • Yes please - I think this would be good, it should show what's going on with MCP under the hood.

3. OpenRouter Integration

• Should we implement the full OpenRouter OAuth flow immediately, or start with a simpler approach (like API key input) and add OAuth later?
  • I think we could start with an API key input if that's easier, as our useContext provider should be pluggable
• Do you want to support other inference providers from the start, or focus on OpenRouter first?
  • I would like to support other providers pretty soon after writing this - we should only start with OpenRouter for now, but make sure our interfaces abstract this away.
• Any preference for model selection UX (dropdown, autocomplete, etc.)?
  • Dropdown for model selection.

4. Conversation & Agent Loop

• How should we handle concurrent conversations across multiple servers? Separate tabs, unified view, or separate windows?
  • Have tabs in the SPA, this functionality isn't super important to start with, however it would be nice if our code accounts for multiple ongoing conversations from the outset
• For the agent loop: should we show tool calls in real-time as they execute, or just show final results?
  • It would be nice to show the toolcall block (while we await the result), and then show the result when it arrives. The user should see what the tool call parameters are.
• Any preference for message persistence strategy (localStorage, IndexedDB, external storage)?
  • Up to you - whatever is easiest

5. MCP Server Discovery & Connection

• Should we implement both HTTP and stdio transports from the start, or focus on HTTP for browser deployment?
  • We will never support stdio from this application. We only want the SSE and SHTTP transports.
• Do you want support for unauthenticated MCP servers, or should everything go through OAuth flows?
  • We should allow for unauthed MCP servers.
• Any specific error handling/retry strategies you prefer?
  • Clear error messages on failure for now is enough. We can think about strengthening this later.

6. Development Approach

• Would you prefer to build this incrementally (start with basic connection + chat, then add multi-server, then agent loop)?
  • Incremental is preferred, I think we can try build out the components first - i.e. the inference provider abstraction, the mcp connection (maybe with something like use-mcp but supporting multiple servers), the agent loop (it would be nice to have the agent loop as a modular hook also, maybe passed in via a provider also)
• Should we create reusable components that could be published as a library later, or focus on the specific app?
  • Keep this in mind for modularity, but it is not a goal at this point.
• Any testing preferences (unit tests, integration tests, manual testing only)?
  • I would like the modular components to have unit tests and integration tests.

7. Deployment & Hosting

• Since this is statically served, any preference for deployment target (Vercel, Netlify, GitHub Pages, etc.)?
  • Let's not worry about this now - ideally it wouldn't affect our design choices.
• Should we set up CI/CD from the start, or handle that later?
  • Handle that later - what is important is that it is easy to set things up and run tests.

These clarifications will help ensure the implementation matches your vision and requirements exactly.