feat: MCP server management UI (#538)

[bergeouss]

Add full MCP server management to the WebUI Settings > System panel.

Backend: GET/PUT/DELETE /api/mcp/servers endpoints with masked secrets. Frontend: server list with transport badges, add/edit/delete form. i18n: 21 keys in 7 locales. 21 tests. Closes #538

[nesquena-hermes]

Thanks for this PR! MCP server management in the Settings > System panel is a highly requested feature (#538), and the implementation scope looks right — REST endpoints with masked secrets on the backend, a management UI on the frontend, and i18n coverage across 7 locales.

A few things to confirm before merge:

Secret masking semantics
The GET /api/mcp/servers endpoint returns masked secrets. Confirming: is the masked value a fixed placeholder (e.g. "***") or a partial reveal (e.g. "sk-...xyz")? And does PUT /api/mcp/servers handle a masked-value submission as "leave secret unchanged" vs. treating it as a literal update? This is a common footgun where a round-trip edit accidentally overwrites a real secret with the masked placeholder.

Transport badge types
What transport types does the badge cover? At minimum stdio and http/sse — are there others? Confirming the badge handles unknown/future transport types gracefully (e.g. falls back to the raw string rather than erroring).

DELETE endpoint safety
Does DELETE /api/mcp/servers require any confirmation step on the frontend, or is deletion immediate? A mistaken delete of a configured server could silently break tool availability. Even a simple "are you sure?" modal would be a good guard.

21 tests: good coverage for a new API surface. Are the tests covering the masked-secret round-trip case (edit and re-submit with masked value should not overwrite the stored secret)?

Once the above are confirmed, this looks ready!

[nesquena-hermes]

Thanks for the follow-up commit — the masked-value round-trip protection directly addresses the concern raised above. Confirming that PUT now treats a masked placeholder as "leave secret unchanged" rather than overwriting is exactly the right semantics.

If the other points (transport badge unknown-type fallback, DELETE confirmation) are also addressed or were already handled in the original implementation, this is ready to go. Looking good!

[bergeouss]

Review Feedback Follow-up

Thanks for the confirmation on the masked-value round-trip fix!

Regarding the other two points you asked about — both were already handled in the original implementation:

• Transport badge unknown-type fallback: static/panels.js line 3084 uses a ternary chain that defaults to mcp-unknown class (.mcp-unknown in style.css line 1715) when the transport type is neither http nor stdio.

  const transportClass=s.transport==='http'?'mcp-http':s.transport==='stdio'?'mcp-stdio':'mcp-unknown';

• DELETE confirmation: deleteMcpServer() in static/panels.js line 3142 calls showConfirmDialog() before issuing the DELETE request, with danger: true and focusCancel: true flags.

  const _ok=await showConfirmDialog({title:t('mcp_delete_confirm_title'),message:t('mcp_delete_confirm_message',name),confirmLabel:t('delete_title'),danger:true,focusCancel:true});

Both are covered — ready for merge whenever you are. 🚀

🤖 AI-assisted via Hermes Agent