Torvian.eu/chatbot
Watch
1
0
Fork
You've already forked chatbot
 0
Code Issues Pull requests Projects Releases 12 Packages Wiki Activity Actions

Phase 3: MCP Tool Discovery and Refresh #125

New issue
Closed
opened 2025-11-22 22:49:29 +00:00 by rwachters · 0 comments
rwachters commented 2025-11-22 22:49:29 +00:00 (Migrated from github.com)

Phase 3: MCP Tool Discovery and Refresh

Epic: NF.EA1 - Local MCP Servers

Description

This issue focuses on implementing the tool discovery and refresh mechanism. The user needs to be able to query a configured local MCP server to see what tools it offers and persist them. Furthermore, if the tools on the MCP server change, the user must be able to refresh the list to see the updates.

This process is client-driven: the client will start the local server, perform the MCP discovery, and then send the results to the backend for persistence.

User Stories & Acceptance Criteria

✅ Task Checklist

  • US3.1: Implement Local MCP Tool Discovery and Persistence

    • Add a "Discover Tools" button to the MCP server management UI.
    • On the client, clicking the button should trigger a flow in LocalMCPServerManager:
      • Start the selected local MCP server process.
      • Use the MCPClientService to execute the discoverTools MCP command.
      • Send the retrieved list of ToolDefinitions to the backend via a new API endpoint (e.g., POST /api/v1/local-mcp-servers/{serverId}/tools/sync).
      • Stop the local MCP server process after discovery is complete.
    • On the server, create the new API endpoint to receive the list of tools.
    • The server-side service logic should:
      • Validate that the user owns the specified MCP server.
      • Persist the new tool definitions in the ToolDefinitionTable.
      • Link each new tool to the LocalMCPServer via the LocalMCPToolDefinitionTable.
    • The client UI should update to display the newly discovered tools associated with the server.

  • US3.2: Implement Tool Refresh Mechanism

    • The "Discover Tools" button should be repurposed as a "Refresh Tools" button after the initial discovery.
    • When the refresh flow is triggered, the client repeats the discovery process from US3.1.
    • The server-side synchronization endpoint (/sync) must be enhanced to handle updates intelligently:
      • Identify New Tools: Add any tools from the incoming list that are not already in the database for that server.
      • Identify Updated Tools: For tools that already exist (matched by name), update their properties (description, parameters, etc.).
      • Identify Removed Tools: Delete any tools from the database that are associated with this server but are not present in the new list from the client.
    • The entire refresh operation on the server should be performed within a single database transaction to ensure data consistency.

Architectural Context

  • Client-Driven Workflow: The client is responsible for orchestrating the entire discovery process. It manages the lifecycle of the local OS process, initiates the MCP communication, and pushes the results to the server. This design keeps the server agnostic of the complexities of managing local processes and speaking MCP.

  • Stateless Server API: The server exposes a stateless API endpoint (/sync) that accepts a complete list of tools for a given MCP server. This makes the server's logic robust and idempotent. It doesn't need to know the previous state; it simply synchronizes its database to match the state provided by the client.

  • Synchronization Logic: The core of this phase is the server-side synchronization logic. This logic must correctly diff the incoming tool list against the existing persisted tools for that server and perform the necessary create, update, and delete operations. Encapsulating this in a transactional service method (e.g., ToolService.synchronizeMcpTools) is critical for maintaining data integrity.

# Phase 3: MCP Tool Discovery and Refresh **Epic**: `NF.EA1 - Local MCP Servers` ## Description This issue focuses on implementing the tool discovery and refresh mechanism. The user needs to be able to query a configured local MCP server to see what tools it offers and persist them. Furthermore, if the tools on the MCP server change, the user must be able to refresh the list to see the updates. This process is client-driven: the client will start the local server, perform the MCP discovery, and then send the results to the backend for persistence. --- ## User Stories & Acceptance Criteria ### ✅ Task Checklist - [ ] **US3.1: Implement Local MCP Tool Discovery and Persistence** - [ ] Add a "Discover Tools" button to the MCP server management UI. - [ ] On the client, clicking the button should trigger a flow in `LocalMCPServerManager`: - [ ] Start the selected local MCP server process. - [ ] Use the `MCPClientService` to execute the `discoverTools` MCP command. - [ ] Send the retrieved list of `ToolDefinition`s to the backend via a new API endpoint (e.g., `POST /api/v1/local-mcp-servers/{serverId}/tools/sync`). - [ ] Stop the local MCP server process after discovery is complete. - [ ] On the server, create the new API endpoint to receive the list of tools. - [ ] The server-side service logic should: - [ ] Validate that the user owns the specified MCP server. - [ ] Persist the new tool definitions in the `ToolDefinitionTable`. - [ ] Link each new tool to the `LocalMCPServer` via the `LocalMCPToolDefinitionTable`. - [ ] The client UI should update to display the newly discovered tools associated with the server. - [ ] **US3.2: Implement Tool Refresh Mechanism** - [ ] The "Discover Tools" button should be repurposed as a "Refresh Tools" button after the initial discovery. - [ ] When the refresh flow is triggered, the client repeats the discovery process from US3.1. - [ ] The server-side synchronization endpoint (`/sync`) must be enhanced to handle updates intelligently: - **Identify New Tools**: Add any tools from the incoming list that are not already in the database for that server. - **Identify Updated Tools**: For tools that already exist (matched by name), update their properties (description, parameters, etc.). - **Identify Removed Tools**: Delete any tools from the database that are associated with this server but are *not* present in the new list from the client. - [ ] The entire refresh operation on the server should be performed within a single database transaction to ensure data consistency. --- <details> <summary><h3>Architectural Context</h3></summary> - **Client-Driven Workflow**: The client is responsible for orchestrating the entire discovery process. It manages the lifecycle of the local OS process, initiates the MCP communication, and pushes the results to the server. This design keeps the server agnostic of the complexities of managing local processes and speaking MCP. - **Stateless Server API**: The server exposes a stateless API endpoint (`/sync`) that accepts a complete list of tools for a given MCP server. This makes the server's logic robust and idempotent. It doesn't need to know the previous state; it simply synchronizes its database to match the state provided by the client. - **Synchronization Logic**: The core of this phase is the server-side synchronization logic. This logic must correctly diff the incoming tool list against the existing persisted tools for that server and perform the necessary create, update, and delete operations. Encapsulating this in a transactional service method (e.g., `ToolService.synchronizeMcpTools`) is critical for maintaining data integrity. </details>
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
test/credential-validator-fixture-umask
feat/credential-profile-agent-roles
fix/credential-secret-tree-removal
feat/terminal-session-credential-attach
feat/worker-terminal-session
feat/worker-command-uid-isolation
v0.11.0
v0.10.0
v0.9.0
v0.8.0
v0.7.0
v0.6.0
v0.5.1
v0.5.0
v0.4.0
v0.3.0
v0.2.0
v0.1.0
Labels
Clear labels   
Epic 5

   
MCP

   
P1

   
PR-0

   
PR-1

   
api

   
api-layer

   
architecture

   
area:backend

   
area:frontend

   
arrow

   
authentication

   
backend

   
bug
Something isn't working

  
chat

   
client

   
clipboard

   
common-module

   
compose

   
cross-cutting

   
cross-cutting-requirement

   
data-layer

   
data-models

   
database

   
desktop-client

   
documentation
Improvements or additions to documentation

  
duplicate
This issue or pull request already exists

  
enhancement
New feature or request

  
epic

   
epic-1

   
epic-2

   
epic-3

   
epic-4

   
epic-5

   
epic-6

   
epic-7

   
epic-llm-config

   
error-handling

   
feature

   
frontend

   
good first issue
Good for newcomers

  
help wanted
Extra attention is needed

  
implementation

   
infrastructure

   
installer

   
invalid
This doesn't seem right

  
kotlin

   
ktor

   
llm

   
medium-priority

   
message

   
multiplatform

   
needs-review

   
needs-triage

   
packaging

   
performance

   
phase-1

   
phase-2

   
phase-3

   
phase-4

   
phase-5

   
phase3

   
phase:3

   
priority: high

   
question
Further information is requested

  
refactor

   
refactoring

   
resource-sharing

   
security

   
server

   
server-module

   
services

   
session

   
session-management

   
settings

   
setup

   
shutdown

   
state

   
storage

   
streaming

   
sub-issue

   
tests

   
tooling

   
type:task

   
ui

   
ui/ux

   
user-accounts

   
user-management

   
ux

   
viewmodel

   
websocket

   
windows

   
windows-integration

   
wontfix
This will not be worked on

No labels
Epic 5
MCP
P1
PR-0
PR-1
api
api-layer
architecture
area:backend
area:frontend
arrow
authentication
backend
bug
chat
client
clipboard
common-module
compose
cross-cutting
cross-cutting-requirement
data-layer
data-models
database
desktop-client
documentation
duplicate
enhancement
epic
epic-1
epic-2
epic-3
epic-4
epic-5
epic-6
epic-7
epic-llm-config
error-handling
feature
frontend
good first issue
help wanted
implementation
infrastructure
installer
invalid
kotlin
ktor
llm
medium-priority
message
multiplatform
needs-review
needs-triage
packaging
performance
phase-1
phase-2
phase-3
phase-4
phase-5
phase3
phase:3
priority: high
question
refactor
refactoring
resource-sharing
security
server
server-module
services
session
session-management
settings
setup
shutdown
state
storage
streaming
sub-issue
tests
tooling
type:task
ui
ui/ux
user-accounts
user-management
ux
viewmodel
websocket
windows
windows-integration
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Torvian.eu/chatbot#125
No description provided.