[Enhancement]: Thread Id in MCP headers #8017
Description
What features would you like to see added?
📌 Feature Request: Add a User’s Thread ID Placeholder
Background:
Currently, the LibreChat MCP System provides several useful placeholders for user-related fields (e.g., {{LIBRECHAT_USER_NAME}}, {{LIBRECHAT_USER_EMAIL}}, {{LIBRECHAT_USER_ROLE}}), but there is no built-in placeholder to dynamically include the unique thread ID associated with a user’s current conversation session.
Problem:
Many integrations, custom logging pipelines, and external systems require a stable reference to a specific conversation (thread) for auditing, correlation, or multi-turn context management. Without a dedicated thread identifier in the MCP headers, developers must implement workarounds or custom middleware to inject this information manually.
Request:
✅ Add a new standard placeholder to the MCP header system:
| Placeholder | User Field | Type | Description |
|---|---|---|---|
| {{LIBRECHAT_USER_THREAD_ID}} | threadId | String | The unique ID of the user’s current conversation thread |
Proposed Behavior:
-
The new placeholder should resolve to the conversation’s unique thread UUID (or database ID) that LibreChat uses internally to track the chat session.
-
If a user has multiple concurrent threads, it should resolve to the thread currently being processed.
-
If no thread exists, it should resolve to an empty string or
null.
Use Cases:
-
Allow downstream systems (analytics, CRM, AI backends) to correlate chat logs and user actions by thread.
-
Improve debugging and monitoring by clearly tagging requests with both user ID and thread ID.
-
Enable multi-thread workflows where the same user can have separate conversations tracked cleanly.
Priority:
Medium–High. This is a fundamental addition that enhances auditability and integration flexibility for developers and enterprise users.
Example:
Header: X-LibreChat-Thread: {{LIBRECHAT_USER_THREAD_ID}}
Please confirm if this feature is feasible and if it can be prioritized for the next MCP schema update.
I’d be happy to provide additional context or help test the implementation.
Thank you for considering this enhancement!
More details
Current documentation state these placeholders:
https://www.librechat.ai/docs/configuration/librechat_yaml/object_structure/mcp_servers
| Placeholder | User Field | Type | Description |
|---|---|---|---|
{{LIBRECHAT_USER_NAME}} |
name |
String | User’s display name |
{{LIBRECHAT_USER_USERNAME}} |
username |
String | User’s username |
{{LIBRECHAT_USER_EMAIL}} |
email |
String | User’s email address |
{{LIBRECHAT_USER_PROVIDER}} |
provider |
String | Authentication provider (e.g., “email”, “google”, “github”) |
{{LIBRECHAT_USER_ROLE}} |
role |
String | User’s role (e.g., “user”, “admin”) |
{{LIBRECHAT_USER_GOOGLEID}} |
googleId |
String | Google account ID |
{{LIBRECHAT_USER_FACEBOOKID}} |
facebookId |
String | Facebook account ID |
{{LIBRECHAT_USER_OPENIDID}} |
openidId |
String | OpenID account ID |
{{LIBRECHAT_USER_SAMLID}} |
samlId |
String | SAML account ID |
{{LIBRECHAT_USER_LDAPID}} |
ldapId |
String | LDAP account ID |
{{LIBRECHAT_USER_GITHUBID}} |
githubId |
String | GitHub account ID |
{{LIBRECHAT_USER_DISCORDID}} |
discordId |
String | Discord account ID |
{{LIBRECHAT_USER_APPLEID}} |
appleId |
String | Apple account ID |
{{LIBRECHAT_USER_EMAILVERIFIED}} |
emailVerified |
Boolean → String | Email verification status (“true” or “false”) |
{{LIBRECHAT_USER_TWOFACTORENABLED}} |
twoFactorEnabled |
Boolean → String | 2FA status (“true” or “false”) |
{{LIBRECHAT_USER_TERMSACCEPTED}} |
termsAccepted |
Boolean → String | Terms acceptance status (“true” or “false”) |
Which components are impacted by your request?
Other
Pictures
No response
Code of Conduct
- I agree to follow this project's Code of Conduct