refact: rename hub into agents and add system prompt support (#2197)

* Refactor terminology from "Hubs" to "Agents" across documentation and UI components. Update descriptions and references to reflect the new terminology, ensuring consistency in the context of MCP Mesh functionality. Additionally, introduce a new hook for managing system prompts specific to agents.

* Update documentation to replace "Hubs" with "Agents" for consistency across MCP Mesh references. Adjust descriptions and instructions in multiple files to reflect this terminology change, ensuring clarity in the context of virtual server functionality.

* Refactor extractConnectionData function for improved readability and consistency. Removed unnecessary line breaks and cleaned up the code structure. Removed unused findRegistryItemByBinding function to streamline the utility file.

* fmt

* Update text in ConnectionGatewaysSection to clarify that the connection is used on agents instead of being exposed via agents, enhancing consistency with recent terminology changes.

* Update documentation and code references to replace "Hubs" with "Agents" throughout the MCP Mesh, ensuring consistency in terminology. Adjust descriptions, instructions, and error messages to reflect the new terminology, enhancing clarity in the context of virtual server functionality.

* Update documentation and code references to consistently replace "Gateways" with "Agents" in the MCP Mesh, ensuring clarity and uniformity in terminology across multiple files.

* Update documentation and code references to consistently replace "Gateways" with "Agents" across multiple files, enhancing clarity and uniformity in terminology within the MCP Mesh.

Author: tlgimenes

apps/docs/client/src/content/en/introduction.mdx

@@ -93,7 +93,7 @@ The application will be available at `http://localhost:8080`.
 - **[Quickstart](/en/mcp-mesh/quickstart)**
 - **[Concepts](/en/mcp-mesh/concepts)**
 - **[MCP Servers (Connections)](/en/mcp-mesh/mcp-servers)**
-- **[MCP Gateways](/en/mcp-mesh/mcp-gateways)**
+- **[MCP Agents](/en/mcp-mesh/mcp-gateways)**
 - **[API Keys](/en/mcp-mesh/api-keys)**
 - **[Monitoring](/en/mcp-mesh/monitoring)**
 

apps/docs/client/src/content/en/mcp-mesh/api-keys.mdx

@@ -1,6 +1,6 @@
 ---
 title: API Keys
-description: Create scoped API keys to access management tools, proxies, and gateways
+description: Create scoped API keys to access management tools, proxies, and agents
 icon: KeyRound
 ---
 
@@ -18,7 +18,7 @@ API keys are the simplest way to give an agent/app access to the Mesh without an
 
 - **Least privilege**: only grant the tool permissions you need.
 - **Separate keys per workload**: one key per app/agent is easier to rotate.
-- **Use gateways for surface control**: combine API-key permissions with a curated gateway.
+- **Use agents for surface control**: combine API-key permissions with a curated agent.
 
 <Callout type="warning">
   Treat API keys like production secrets. Store them in a secrets manager and rotate regularly.

apps/docs/client/src/content/en/mcp-mesh/api-reference.mdx

@@ -1,6 +1,6 @@
 ---
 title: API Reference
-description: The core HTTP endpoints exposed by the Mesh for MCP, gateways, OAuth, and ops
+description: The core HTTP endpoints exposed by the Mesh for MCP, agents, OAuth, and ops
 icon: Code
 ---
 
@@ -10,18 +10,18 @@ icon: Code
 
 - `POST /mcp`
 
-This endpoint exposes **management tools** via MCP (orgs, connections, gateways, API keys, monitoring, event bus).
+This endpoint exposes **management tools** via MCP (orgs, connections, agents, API keys, monitoring, event bus).
 
 ### Connection proxy
 
 - `POST /mcp/:connectionId`
 
 Proxies MCP requests to a single upstream connection.
 
-### Gateway (virtual server)
+### Agent (virtual server)
 
 - `POST /mcp/gateway/:gatewayId`
-- `POST /mcp/gateway` (default Hub; requires `x-org-id` or `x-org-slug`)
+- `POST /mcp/gateway` (default Agent; requires `x-org-id` or `x-org-slug`)
 
 Aggregates tools/resources/prompts across multiple connections.
 

apps/docs/client/src/content/en/mcp-mesh/authorization-and-roles.mdx

@@ -39,6 +39,6 @@ API keys are created with explicit permissions for specific management tools (an
 
 - **Members**: manage roles and invitations
 - **API Keys**: create/update/delete keys and restrict permissions
-- **Gateways**: expose only the desired tool surface (include/exclude strategies)
+- **Agents**: expose only the desired tool surface (include/exclude strategies)
 
 

apps/docs/client/src/content/en/mcp-mesh/concepts.mdx

@@ -1,17 +1,17 @@
 ---
 title: Concepts
-description: The mental model for organizations, connections, gateways, API keys, and tool calls
+description: The mental model for organizations, connections, agents, API keys, and tool calls
 icon: BookOpen
 ---
 
 ## Core entities
 
-- **Organization**: the top-level tenant boundary. Everything (connections, gateways, logs) is org-scoped.
+- **Organization**: the top-level tenant boundary. Everything (connections, agents, logs) is org-scoped.
 - **Members**: users invited into an organization.
 - **Roles**: role assignments for members, used by access control checks.
 - **Connection**: a configured upstream MCP endpoint (usually HTTP), optionally with stored credentials.
-- **Hub**: a virtual MCP server that aggregates multiple connections into a single MCP surface.
-- **Tool call**: a `tools/call` request routed through the Mesh to a downstream MCP server (or via a gateway).
+- **Agent**: a virtual MCP server that aggregates multiple connections into a single MCP surface.
+- **Tool call**: a `tools/call` request routed through the Mesh to a downstream MCP server (or via an agent).
 - **Monitoring log**: a record of a tool call (inputs, outputs, duration, error), used for debugging and ops.
 
 ## Data and security boundaries
@@ -25,7 +25,7 @@ icon: BookOpen
 2. The client calls either:
    - the **Management MCP** (admin tools), or
    - a **Proxy endpoint** (one connection), or
-   - a **Hub endpoint** (aggregated tools/resources/prompts).
+   - an **Agent endpoint** (aggregated tools/resources/prompts).
 3. The Mesh authorizes, loads credentials, proxies to the downstream Connection(s), and logs monitoring events.
 
 

apps/docs/client/src/content/en/mcp-mesh/connect-clients.mdx

@@ -17,10 +17,10 @@ There are two common ways to connect clients to the Mesh:
 
 - **Management MCP**: `POST /mcp`
 - **Connection proxy**: `POST /mcp/:connectionId`
-- **Hub (virtual server)**: `POST /mcp/gateway/:gatewayId` (or omit `:gatewayId` to use the org default Hub with headers)
+- **Agent (virtual server)**: `POST /mcp/gateway/:gatewayId` (or omit `:gatewayId` to use the org default Agent with headers)
 
 <Callout type="tip">
-  If your goal is a "single MCP URL" for a curated tool surface, use **Hubs**. If you want a direct pipe to one upstream MCP, use **Connection proxy**.
+  If your goal is a "single MCP URL" for a curated tool surface, use **Agents**. If you want a direct pipe to one upstream MCP, use **Connection proxy**.
 </Callout>
 
 ## Authentication quick notes

apps/docs/client/src/content/en/mcp-mesh/mcp-gateways.mdx

@@ -1,14 +1,14 @@
 ---
-title: Hubs
+title: Agents
 description: Publish a virtual MCP server that aggregates tools/resources/prompts from multiple connections
 icon: Waypoints
 ---
 
 import Callout from "../../../components/ui/Callout.astro";
 
-## What is a Hub?
+## What is an Agent?
 
-A **Hub** is a **virtual MCP server** that aggregates multiple connections into a single MCP surface:
+An **Agent** is a **virtual MCP server** that aggregates multiple connections into a single MCP surface:
 
 - tools (`tools/list`, `tools/call`)
 - resources (`resources/list`, `resources/read`)
@@ -20,7 +20,7 @@ This is how you create a curated endpoint for clients without exposing every too
 
 - `POST /mcp/gateway/:gatewayId`
 
-You can also omit `:gatewayId` and rely on the organization's default Hub by providing one of these headers:
+You can also omit `:gatewayId` and rely on the organization's default Agent by providing one of these headers:
 
 - `x-org-id`, or
 - `x-org-slug`
@@ -32,12 +32,12 @@ You can also omit `:gatewayId` and rely on the organization's default Hub by pro
 
 ## Tool exposure strategies
 
-Hubs also control **how tools are exposed** to clients (useful when tool surfaces get large).
+Agents also control **how tools are exposed** to clients (useful when tool surfaces get large).
 These strategies ship by default:
 
 ### Passthrough (baseline)
 
-- Exposes all gateway tools directly via `tools/list`.
+- Exposes all agent tools directly via `tools/list`.
 - Best for small tool surfaces and deterministic behavior.
 
 ### Smart tool selection
@@ -56,20 +56,20 @@ These strategies ship by default:
   - `GATEWAY_RUN_CODE` (run JS in a sandbox that can call tools)
 - Goal: reduce tool exposure overhead on large surfaces by shifting work into a constrained runtime.
 
-## The default Hub (auto-created per org)
+## The default Agent (auto-created per org)
 
-Every new organization gets a **Default Hub**:
+Every new organization gets a **Default Agent**:
 
 - **Strategy**: `passthrough`
 - **Mode**: `exclusion`
 - **Default exclusions**: the built-in **Mesh MCP** connection (management tools) and the **Store/Registry** connection are excluded by default
-- **Default behavior**: everything else in the org is included — so as you connect Integrations, this endpoint becomes the "all tools in the org" Hub
+- **Default behavior**: everything else in the org is included — so as you connect Integrations, this endpoint becomes the "all tools in the org" Agent
 
 This is the endpoint most teams use as the single aggregated MCP surface for an org.
 
 ## Benchmark: strategy tradeoffs
 
-We ran a gateway strategy benchmark here: [MCP Gateway Benchmark (GitHub Actions run)](https://github.com/decocms/mesh/actions/runs/20584203227).
+We ran an agent strategy benchmark here: [MCP Agent Benchmark (GitHub Actions run)](https://github.com/decocms/mesh/actions/runs/20584203227).
 
 **Summary (high level):**
 

apps/docs/client/src/content/en/mcp-mesh/mcp-servers.mdx

@@ -33,7 +33,7 @@ The Mesh will:
 5. log a monitoring event
 
 <Callout type="info">
-  If you need a single aggregated endpoint for multiple connections, use [Hubs](/en/mcp-mesh/mcp-gateways) instead.
+  If you need a single aggregated endpoint for multiple connections, use [Agents](/en/mcp-mesh/mcp-gateways) instead.
 </Callout>
 
 

apps/docs/client/src/content/en/mcp-mesh/monitoring.mdx

@@ -1,6 +1,6 @@
 ---
 title: Monitoring
-description: Inspect tool calls, errors, and latency across connections and gateways
+description: Inspect tool calls, errors, and latency across connections and agents
 icon: Activity
 ---
 
@@ -9,7 +9,7 @@ icon: Activity
 The Mesh records monitoring logs for proxied tool calls, including:
 
 - tool name
-- connection / gateway attribution
+- connection / agent attribution
 - user identity (user ID or API key user)
 - duration and error status
 - inputs and output (normalized)
@@ -19,7 +19,7 @@ The Mesh records monitoring logs for proxied tool calls, including:
 Go to **Monitoring** to:
 
 - view tool call volume, errors, and latency
-- filter by tool/connection/gateway/status
+- filter by tool/connection/agent/status
 - tail logs via **Streaming**
 - drill into individual calls
 
@@ -28,7 +28,7 @@ Go to **Monitoring** to:
 Monitoring is the backbone for:
 
 - debugging broken tool calls
-- verifying permissions and gateway selection
+- verifying permissions and agent selection
 - tracking latency regressions and error spikes
 
 

apps/docs/client/src/content/en/mcp-mesh/overview.mdx

@@ -28,17 +28,17 @@ The Mesh centralizes these concerns once, so you can operate MCP traffic like an
 │ MCP Clients       │   │ MCP Mesh (Proxy) │   │ Downstream MCPs     │
 │ - Cursor          │──▶│ - AuthN/AuthZ    │──▶│ - Slack / Gmail     │
 │ - Claude Desktop  │   │ - Vault          │   │ - Notion / Stripe   │
-│ - Custom agents   │   │ - Gateways       │   │ - Your MCP servers  │
+│ - Custom agents   │   │ - Agents         │   │ - Your MCP servers  │
 └───────────────────┘   │ - Monitoring     │   └────────────────────┘
                         └──────────────────┘
 ```
 
 ## What the Mesh centralizes
 
 - **Routing + execution**: which MCP to call and how to authenticate it
-- **Policy enforcement**: who can access which tools (and through which gateways)
+- **Policy enforcement**: who can access which tools (and through which agents)
 - **Observability**: logs, latency, errors, and request context across tool calls
-- **Runtime strategies (gateways)**: different exposure strategies as tool surfaces grow
+- **Runtime strategies (agents)**: different exposure strategies as tool surfaces grow
 
 ## Product surfaces (what you can do today)