Context Forge currently discovers and registers tools from an MCP gateway only at initial gateway registration (or process startup).

When an MCP server exposes dynamic tools (tools added, removed, or modified at runtime), there is no supported mechanism in Context Forge to re-discover or refresh the tool catalog for an already-registered gateway.

This makes it difficult to operate MCP servers that intentionally support dynamic tool lifecycles.

Observed Behavior

Tools are fetched once during gateway registration.

Subsequent changes in the MCP server’s tools/list output are not reflected in Context Forge.

Updating gateway metadata (PUT), toggling enabled, updating tags, or modifying capabilities does not trigger tool re-discovery.

The only way to reflect tool changes is to:

Deregister the gateway

Re-register it again

Expected / Desired Behavior

Context Forge should support explicit or implicit tool re-discovery for registered gateways, for example:

An API to refresh tools for a gateway

A capability flag (e.g. tools.listChanged=true) that triggers re-listing

A background polling or revalidation mechanism

A webhook or event-driven refresh hook

This would allow Context Forge to safely support MCP servers with dynamic tool sets.

Why This Matters

Many MCP servers (e.g., tool managers, orchestration layers, plug-in systems) are designed to:

Add tools dynamically

Remove deprecated tools

Evolve tool schemas without restarting infrastructure

Without a refresh mechanism:

Users must rely on gateway deregistration, which is disruptive

Tool visibility becomes stale

Dynamic MCP use cases are hard to support cleanly

Reproduction Steps

Register an MCP gateway that exposes tools via tools/list

Verify tools appear in Context Forge

Modify the MCP server to add or remove tools

Observe that Context Forge does not reflect the changes

Deregister and re-register the gateway

Observe that tools are now updated

Proposed Enhancements (Any of the following)

POST /gateways/{id}/tools/refresh

Support tool re-discovery on PUT /gateways/{id}

Capability-based refresh (e.g., capabilities.tools.listChanged)

Optional polling interval per gateway

Admin/API-triggered refresh