Configurable tool notices in the composer, with matching tool colors

[VoidDweller802]

I would like feedback on an optional feature that helps people understand which tools are active and what those tools can do before they send a message.

The proposal adds compact notices inside the message composer, directly above the input. Each notice uses the same colors as its tool control: blue for Web Search, green for File Search, and purple for Run Code. The notice can explain a capability, such as asking questions across uploaded documents or generating downloadable files, or carry deployment-specific guidance such as a Web Search privacy reminder.

I have a local, AI-assisted prototype for discussion. It supports normal chats and saved Agents using LibreChat's built-in Web Search, File Search and Run Code tools. It is not an upstream-approved feature, and I am seeking agreement on the scope and configuration before submitting a pull request.

Proposed behavior

• Optional YAML configuration and an authorized editor under Settings → General → Admin.
• Editable plain-text titles/messages, stable IDs, tool binding, ordering, severity, enablement and dismissal policy.
• Multiple notices stack above the input and disappear when their tool is inactive.
• Optional dismissal hides only that notice; it does not disable a tool or approve execution.
• Conversation or browser-tab dismissal scope, optional reappearance after reactivation, and automatic reappearance after wording or policy changes.
• YAML supplies defaults; persisted administrator overrides merge by notice ID, preserve explicit false values and can be reset.
• Omitted configuration leaves existing installations unchanged.

The existing toolApproval flow remains responsible for execution-time approval. This proposal does not introduce a second approval mechanism, detect sensitive information, or claim coverage of provider-native grounding or MCP notices.

Implementation scope

The shared schema/resolver lives in data-provider; YAML projection and stored configuration resolution use data-schemas; authorized management and cache invalidation live in packages/api. The client adds the composer notice area, dismissal state and a settings editor. Notice colors reuse the existing tool accent definitions.

Prototype evidence

The prototype was built from upstream/dev at ef89fbd. Build, focused configuration/state/API tests and browser scenarios have passed. Browser checks include exact color matching in light/dark themes, normal chats, a saved Agent, reload, tool toggling and admin changes. Captures show the current running app with the updated default wording.

The local demo uses mock services. The required Lighthouse performance gate has not passed: it stopped at a Windows temporary-directory cleanup error. A counted external Web Search approval experiment also remains unverified; the existing MCP approval regression tests are separate evidence.

Would this be a useful addition, and is this configuration shape appropriate? If the scope is approved, I would like to work on an assigned issue and prepare one PR targeting dev. I am happy to adjust the copy, visual treatment or editor placement to match maintainer preferences.