Make MCP node installations register with our database

[gstout52]

Description

With the MCP nodes, users are able to create MCP servers hosted by their instances. To make use of those servers they have to provide details of the endpoints to their MCP client. Currently we don't help them do that.

With our work on FF Expert, a time will come where we'd like them to be able to interact with their MCP servers via the FF UI. To achieve that, the FF Expert will need to know what MCP servers the team has created.

The purpose of this issue is to create a mechanism where the platform has a list of MCP server endpoints owned by the Team.

The end result should be an admin api end point somewhere under /api/v1/teams/:teamid/.... which returns an appropriate collection of MCP server details. The specific structure of that needs to be considered; whether there's a standard format that is instantly consumable by MCP Clients for example.

The main engineering challenge is how to keep that list up to date and accurate given the dynamic way flows can be created/suspended/rolled-back etc.

Possible approaches will be:

1. Have the MCP nodes call a platform API when they are deployed with details of their configuration.
   • The challenge here is how to remove the details when the node is removed, instance is rolled back, instance is suspended etc - as there's no hook for the node to unregister itself
2. Have a way for the platform to poll the instances via a launcher admin endpoint to get a list of the current deployed endpoints.
   • Similar lifecycle issues and requires lots of instance polling for large teams 'just in case' they are using MCP nodes
   • Also hard to achieve for remote instances
3. Something else...

[knolleary]

We already have https://github.com/FlowFuse/flowfuse/pull/6017 in progress as part of gathering stats on certified node usage. Would extending that to include our FF Exclusive nodes satisfy this requirement?

[hardillb]

Going to need a whole bunch more context here.

Which "database"? As these nodes are only currently available in the FlowFuse exclusive catalogue we already have a PR to enable telemetry to track how many NR instances have them installed in a given FF instance (https://github.com/FlowFuse/flowfuse/pull/6017).

There isn't an install event we can hook without adding a post install script to the npm package.

Also I haven't used these node at all, but these are "server" nodes for want of a better description so not sure what you mean by "connections" here, I'll look at what we get, but at best we may be able to get the IP address of the MCP client, but there could be 100s (if not 1000s) of requests made in a short space of time.

[hardillb]

@knolleary that PR already also tracks @flowfuse-nodes scoped packages (and is ready for a second review)

[knolleary]

@hardillb great - sorry, I could have checked that.

But, it occurs to me our tracking only considers if the node is installed. We agreed that was sufficient for Cert Nodes as the nodes don't get installed by default.

For our own nodes, if we preinstall them, then the usage reporting won't reflect actual usage.

@gstout52 can you reframe this as a problem statement? What data do you want to be able to track? We can then work out what makes sense to do.

[ZJvandeWeg]

@hardillb @knolleary To use a MCP resource or tool, some details will be needed by the LLM. That LLM interface will soon live in FlowFuse to remove the burden of using MCP nodes, registering in VScode or elsewhere, and interacting in multiple places to get things done.

This issue is for the MCP resource or tool to make itself available for that prompt

[gstout52]

@knolleary Following Product Planning today, please revise the issue description.

[knolleary]

Have updated the description and discussed with @hardillb to get him up to speed on the requirement

[hardillb]

@Steve-Mcl I will need some time with you to try and add some scope to this and what it possible.

My view is that polling any Hosted Instance marked as running is the only sensible approach and adding an endpoint that can be polled (via the nr-launcher) to the mpc nodes is way forward.

But I also have no idea of what information from the MPC nodes is useful

[ZJvandeWeg]

@hardillb Why wouldn't any instance, hosted or remote, push on connect to FlowFuse? I suspect that remote instances are move valuable too for the MCP nodes, as that way the resources on the edge can be queried etc through a text interface. Should we start with remote instances instead?

[hardillb]

@ZJvandeWeg This is discussed in the update opening comment. I still think option 2 is the best way to not end up with lots of stale data in the database with no easy way to evict it.

Also there is no guarantee that anything other than the forge app can reach a remote instance, large numbers of devices can only reach out, but we can send messages to the device agent to get information from that instance.

[knolleary]

This highlights a key technical issue we'll need to think about; @hardillb has alluded to it but I want to make it explicit.

MCP Servers are exposed via inbound HTTP requests.

When running an MCP Server on a Hosted Instance, we know the external DNS name of the instance and can send HTTP requests to the MCP Server from the FF platform.

When running on a Remote Device, the FF platform cannot make a direct HTTP request to the device - the device connects back to the platform and uses MQTT to proxy interactions. As it stands, that means we can't communicate with the MCP Server on the remote instance from the platform.

This would require as to create a proxy over MQTT, as we do the editor - so we expose the MCP Server on the device via a URL hosted by the platform.

That isn't needed for this initial piece of work (to get a list of what MCP Servers have been created), but will be needed to enable any interaction with remotely hosted mcp servers.

[hardillb]

Idea for a quick iteration here

• New Team level tab to show list of Hosted Instance with MPC nodes installed and a running /mcp endpoint to show they are actually running.
• The tab shows the JSON needed to copy/pasted into e.g. VSCode config

Thoughts @Steve-Mcl ?

[knolleary]

@hardillb that's the sort of thing for where its headed, but want to keep the scope here focused on capturing the right information in the DB and solving the technical challenges to do that. I know @dimitrieh has done a design for the UI (although not sure which issue that's attached to).

Can we have a chat on the whole polling-vs-registering choice?

[hardillb]

Can we have a chat on the whole polling-vs-registering choice?

@knolleary Sure, say when

[dimitrieh]

@knolleary @hardillb there are some designs and discussion over at https://github.com/FlowFuse/flowfuse/issues/6249

[hardillb]

@dimitrieh OK, that looks to be a number of iterations further on than what is covered here.

This is just about exposing what MCP endpoints are available from a Teams instances. Being able to interact with them from within FlowFuse (via FlowFuse Expert) is going to need a lot of architecture work to ensure there is no way to cross over between teams.

[dimitrieh]

@hardillb 100%. The vision needs to be worked out further.

exposing what MCP endpoints are available from a Teams instances.

I am not yet fully up to date here. Do we need a FE for this? OR does this stay a BE update or controlled through nodes or otherwise?

[knolleary]

@dimitrieh there is no FE requirement for this task. It is a precursor to whatever we choose to then do.

[knolleary]

Closing as the work to register endpoints is delivered

[dimitrieh]

@knolleary I didn't see the issue closed yet, so closing it as per your last comment