MCP Servers

Support reference for org MCP server management at `/mcps`.

- Registers MCP servers at the organization level. - Lets staff enable or disable those servers per AI teammate from the AI teammate detail view.

- Page title: `MCP Servers`. - Primary action: `Add`. - Empty state: `No MCP servers`. - Table columns: `Name`, `URL`, `Headers`, `Added`, `Updated`. - Row actions: `Test`, `Edit`, `Delete`. - Bulk action: `Delete`.

- Fields: optional `Name`, required `URL`, optional header key/value pairs. - Create dialog title: `Add MCP Server`. - The create dialog only accepts `http://` and `https://` URLs. - The create dialog blocks duplicate names against the currently loaded org list, and the backend create action also rejects duplicate names. - Unnamed entries are allowed and render as `Unnamed` in the UI. - Edit uses the same fields, but the current edit dialog only checks that URL is non-empty; it does not repeat the create dialog's `http/https` validation in the client. - Backend notes: - create/update accept `headers` as a string-to-string object or `null` - `name` uniqueness is enforced by the database on `(organization_id, name)` - create returns a friendly duplicate-name error; update currently relies on the DB/service path and is less graceful on duplicate names

- Testing starts automatically when the dialog opens. - The current dialog shows: - success or error state - HTTP status - response body when present - The dialog does not currently render response headers. - Backend test flow: - loads the stored MCP record - injects organization variables into URL and headers, including secrets - sends an `initialize` JSON-RPC request - times out after `10s` - starts with protocol version `2025-06-18` - retries once if the server rejects that version and returns a supported version list - Backend response payload includes `status`, `statusText`, `headers`, and `body`; the current UI only surfaces status and body.

- AI teammate detail pages include an `MCPs` tab. - The tab lists all org MCP servers with a checkbox per server. - The current tab reads enabled servers through `GET /api/organizations/{orgId}/mcps?employee_id={employee_id}`. - Checking a box assigns that MCP to the teammate. - Unchecking a box removes the assignment. - The checkbox flow is optimistic in the frontend. - The backend also exposes `GET /api/organizations/{orgId}/mcps/{mcp_id}/employee/{employee_id}`, but the current frontend assignment tab does not use it.

- `GET /api/organizations/{orgId}/mcps` - `POST /api/organizations/{orgId}/mcps` - `GET /api/organizations/{orgId}/mcps/{mcp_id}` - `PUT /api/organizations/{orgId}/mcps/{mcp_id}` - `DELETE /api/organizations/{orgId}/mcps/{mcp_id}` - `GET /api/organizations/{orgId}/mcps/{mcp_id}/test` - `GET /api/organizations/{orgId}/mcps/{mcp_id}/employee/{employee_id}` - `POST /api/organizations/{orgId}/mcps/{mcp_id}/employee/{employee_id}` - `DELETE /api/organizations/{orgId}/mcps/{mcp_id}/employee/{employee_id}`

- Assigned MCP servers are loaded per AI teammate by `MCPBuilder`. - Runtime URL and header values go through organization-variable injection before the client is built. - MCP list/create/get/update/test and assignment routes are AI-accessible through `system.do_organization_action`. - MCP delete remains human-only (`availableToAI: false`). - There is no websocket sync for MCP CRUD in the current org page; the frontend relies on React Query invalidation and refetches.