I have searched all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request.
Problem Description
Currently, the toolIds field in model configuration only sets default tools that are pre-enabled when a user selects a model. However, users can still manually enable/disable any available tool through the Integrations menu during a chat session. This creates a challenge for administrators who want to:
Restrict certain tools (including MCP servers) from being used with specific models
Prevent users from enabling HTTP-based tools that may pose security or cost concerns
Enforce model-specific capabilities based on organizational policies
Current Behavior
Admin configures toolIds in Model Editor (Workspace → Models → Edit)
When user selects the model, tools in toolIds are enabled by default
User can click the Integrations button and toggle ANY available tool on/off
No enforcement mechanism exists to prevent this
Desired Solution you'd like
Add a model-specific tool restriction capability that allows administrators to control which tools can be used with each model, not just which are enabled by default.
Preferred Implementation:
Add a restrict_tools boolean capability to the model configuration (similar to existing vision, file_upload, etc.). When enabled:
Only tools specified in the model's toolIds array can be toggled on
Other tools are hidden or visually disabled in the Integrations menu
Backend validates and rejects requests attempting to use unauthorized tools
UI Changes:
Add checkbox in Model Editor → Capabilities section: "Restrict Tools" with description "Only allow tools specified in the Tools section"
In chat Integrations menu, filter available tools based on model configuration
Show visual indicator (lock icon or grayed out) for restricted models
Backend Enforcement:
Validate tool IDs in utils/middleware.py before processing chat requests
Return appropriate error message if user attempts unauthorized tools
Update model schema to include new capability flag
Backward Compatibility:
Default restrict_tools: false maintains current behavior
Existing models continue to work without modification
Alternatives Considered
Alternatives Considered
1. Tool-level Access Control Only
Use existing access_control on tools to restrict by user/group
Limitation: Can't restrict based on which model is being used, only who is using it
2. Remove Tools from Workspace
Admin removes problematic tools entirely
Limitation: Affects all models globally; can't have tool available for some models but not others
3. Add allowedToolIds or disabledToolIds Array
More explicit allow/deny lists in model metadata
Limitation: More complex to manage, two fields to maintain, less intuitive UX
4. Capability-level Restrictions Instead of Tool-level
Disable tool-calling capability entirely per model via capabilities.tools: false
Limitation: All-or-nothing approach, no granular control over specific tools
5. Custom Pipeline/Filter
Create a filter function that blocks certain tools based on model
Limitation: Requires technical knowledge, not accessible to admins, no UI
Additional Context
Real-World Use Cases:
Security Compliance: Organization wants to prevent web search and HTTP tools from being used with models that process PII/confidential data, while allowing them for general-purpose models
Cost Management: Expensive MCP servers should only be available with premium models, not with standard models
Model Limitations: Some smaller/faster models don't support tool calling well and should have tools disabled entirely
Regulatory Requirements: Healthcare/financial organizations need to enforce which external services can be called based on data classification
User Expectations:
Many admins assume that configuring tools in the Model Editor restricts usage to those tools, similar to how capabilities work. The current behavior where it's only a "default" is surprising and reduces trust in the admin interface.
Similar Features:
Open WebUI already has similar restriction patterns:
capabilities.vision: false prevents image uploads for that model
Tool restriction would follow this same established pattern
Originally created by @hectorc98 on GitHub (Oct 17, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/18392
### Check Existing Issues
- [x] I have searched all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request.
### Problem Description
Currently, the `toolIds` field in model configuration only sets **default tools** that are pre-enabled when a user selects a model. However, users can still manually enable/disable any available tool through the Integrations menu during a chat session. This creates a challenge for administrators who want to:
- Restrict certain tools (including MCP servers) from being used with specific models
- Prevent users from enabling HTTP-based tools that may pose security or cost concerns
- Enforce model-specific capabilities based on organizational policies
### Current Behavior
1. Admin configures `toolIds` in Model Editor (Workspace → Models → Edit)
2. When user selects the model, tools in `toolIds` are enabled by default
3. User can click the Integrations button and toggle **ANY** available tool on/off
4. No enforcement mechanism exists to prevent this
### Desired Solution you'd like
Add a model-specific tool restriction capability that allows administrators to control which tools can be used with each model, not just which are enabled by default.
**Preferred Implementation:**
Add a `restrict_tools` boolean capability to the model configuration (similar to existing `vision`, `file_upload`, etc.). When enabled:
- Only tools specified in the model's `toolIds` array can be toggled on
- Other tools are hidden or visually disabled in the Integrations menu
- Backend validates and rejects requests attempting to use unauthorized tools
**UI Changes:**
- Add checkbox in Model Editor → Capabilities section: "Restrict Tools" with description "Only allow tools specified in the Tools section"
- In chat Integrations menu, filter available tools based on model configuration
- Show visual indicator (lock icon or grayed out) for restricted models
**Backend Enforcement:**
- Validate tool IDs in `utils/middleware.py` before processing chat requests
- Return appropriate error message if user attempts unauthorized tools
- Update model schema to include new capability flag
**Backward Compatibility:**
- Default `restrict_tools: false` maintains current behavior
- Existing models continue to work without modification
### Alternatives Considered
### **Alternatives Considered**
**1. Tool-level Access Control Only**
- Use existing `access_control` on tools to restrict by user/group
- **Limitation:** Can't restrict based on which model is being used, only who is using it
**2. Remove Tools from Workspace**
- Admin removes problematic tools entirely
- **Limitation:** Affects all models globally; can't have tool available for some models but not others
**3. Add `allowedToolIds` or `disabledToolIds` Array**
- More explicit allow/deny lists in model metadata
- **Limitation:** More complex to manage, two fields to maintain, less intuitive UX
**4. Capability-level Restrictions Instead of Tool-level**
- Disable tool-calling capability entirely per model via `capabilities.tools: false`
- **Limitation:** All-or-nothing approach, no granular control over specific tools
**5. Custom Pipeline/Filter**
- Create a filter function that blocks certain tools based on model
- **Limitation:** Requires technical knowledge, not accessible to admins, no UI
### Additional Context
**Real-World Use Cases:**
1. **Security Compliance:** Organization wants to prevent web search and HTTP tools from being used with models that process PII/confidential data, while allowing them for general-purpose models
2. **Cost Management:** Expensive MCP servers should only be available with premium models, not with standard models
3. **Model Limitations:** Some smaller/faster models don't support tool calling well and should have tools disabled entirely
4. **Regulatory Requirements:** Healthcare/financial organizations need to enforce which external services can be called based on data classification
**User Expectations:**
Many admins assume that configuring tools in the Model Editor restricts usage to those tools, similar to how capabilities work. The current behavior where it's only a "default" is surprising and reduces trust in the admin interface.
**Similar Features:**
Open WebUI already has similar restriction patterns:
- `capabilities.vision: false` prevents image uploads for that model
- `capabilities.file_upload: false` disables file inputs
- Tool restriction would follow this same established pattern
users can still manually enable/disable any available tool through the Integrations menu during a chat session.
Not sure if any of this info is helpful, but this is mostly based on my testing and to hopefully be informative.
If you toggle off Allow Chat Valves as a Default Permission in Open WebUI from your superadmin account, users OUTSIDE of any usergroup will no longer see the tools/valves controls for tools in the Integrations menu or Valves within the Chat Controls sidebar.
You and other admins of your Open WebUI instance are unaffected by Default Permissions, so you and other admins will still see the tools/valves controls for tools in the Integrations menu or Valves within the Chat Controls sidebar.
If you toggle off Allow Chat Valves for both the Default Permission and a user-group permission with the admin in aforementioned user-group, the admin will still have access to the tools/valves controls for tools in the Integrations menu and Valves within the Chat Controls sidebar, also unaffected by the toggled state of the Allow Chat Valves permission in the user-group, as the Admin role bypasses this.
Proof:
Default Permissions:
2 Admin accounts - G30 is my superadmin account, Ollama was promoted to Admin for the sake of this example
A new user-group was created for both admins with the Allow Chat Valves toggled off
The Ollama Admin account still has full access to Chat Valves in this scenario
If I change the Ollama user from an Admin back to a User role in the user-group I have it in... I can see tools with Valves access in the Integrations menu, but not the Valves collapsible section in the Chat Controls sidebar.
Lastly, if I remove the Ollama user from the user-group I had it in, then I can no longer see the tools/valves controls for tools in the Integrations menu or Valves within the Chat Controls sidebar, as expected, because the Allow Chat Valves permission has been toggled off this entire time (This loops us back to where we started from).
TL;DR
If “Allow Chat Valves” is off in the global Default Permissions, non-group users simply never see the Valves panel or the per-tool toggles in Integrations; flip the same switch for a user-group and every member of that group inherits the same blindness, but anyone with the Admin role is immune—admins always keep full Valve access no matter how the permission is set at either the default or group level, so the only way an admin can “lose” the controls is by being demoted to a regular user and, at the same time, falling under a group (or the global default) that has the right disabled.
<!-- gh-comment-id:3415960407 -->
@silentoplayz commented on GitHub (Oct 17, 2025):
> users can still manually enable/disable any available tool through the Integrations menu during a chat session.
Not sure if any of this info is helpful, but this is mostly based on my testing and to hopefully be informative.
If you toggle off `Allow Chat Valves` as a Default Permission in Open WebUI from your superadmin account, users **OUTSIDE** of any usergroup will no longer see the tools/valves controls for tools in the `Integrations` menu or `Valves` within the `Chat Controls` sidebar.
<img width="2306" height="1277" alt="Image" src="https://github.com/user-attachments/assets/474f4d96-1c38-41e4-927a-f7000df07fe6" />
You and other admins of your Open WebUI instance are unaffected by `Default Permissions`, so you and other admins will still see the tools/valves controls for tools in the `Integrations` menu or `Valves` within the `Chat Controls` sidebar.
If you toggle off `Allow Chat Valves` for both the Default Permission and a user-group permission with the admin in aforementioned user-group, the admin will still have access to the tools/valves controls for tools in the `Integrations` menu and `Valves` within the `Chat Controls` sidebar, also unaffected by the toggled state of the `Allow Chat Valves` permission in the user-group, as the `Admin` role bypasses this.
## Proof:
### Default Permissions:
<img width="727" height="514" alt="Image" src="https://github.com/user-attachments/assets/90224f37-b64f-47db-b89b-5904de1307ed" />
### 2 `Admin` accounts - `G30` is my superadmin account, `Ollama` was promoted to `Admin` for the sake of this example
<img width="420" height="192" alt="Image" src="https://github.com/user-attachments/assets/1c0315ba-e5a1-44c2-b3a7-f3f8c4408e46" />
### A new user-group was created for both admins with the `Allow Chat Valves` toggled off
<img width="701" height="506" alt="Image" src="https://github.com/user-attachments/assets/8275b038-a440-4c8c-b371-21fd4bf09310" />
<img width="701" height="506" alt="Image" src="https://github.com/user-attachments/assets/030d95d1-0e7a-4101-8704-13e502463348" />
<img width="701" height="506" alt="Image" src="https://github.com/user-attachments/assets/fdf6f93f-17ce-418b-817f-0c54e77f4cd6" />
### The `Ollama` Admin account still has full access to Chat Valves in this scenario
<img width="2559" height="1267" alt="Image" src="https://github.com/user-attachments/assets/717f2e8b-a86a-422e-92c9-aaab43457171" />
<img width="2559" height="1267" alt="Image" src="https://github.com/user-attachments/assets/6860cb99-2885-425d-b5af-b5660fd560c0" />
### If I change the `Ollama` user from an `Admin` back to a `User` role in the user-group I have it in... I can see tools with `Valves` access in the `Integrations` menu, but not the `Valves` collapsible section in the Chat Controls sidebar.
<img width="2559" height="1267" alt="Image" src="https://github.com/user-attachments/assets/ce0caa39-0438-4112-ba3a-f75e6b0b8f8c" />
### Lastly, if I remove the `Ollama` user from the user-group I had it in, then I can no longer see the tools/valves controls for tools in the `Integrations` menu or `Valves` within the `Chat Controls` sidebar, as expected, because the `Allow Chat Valves` permission has been toggled off this entire time (This loops us back to where we started from).
<img width="2559" height="1267" alt="Image" src="https://github.com/user-attachments/assets/e27cc2fc-1ec0-4173-9ce0-47ac9ce33132" />
# TL;DR
**If “Allow Chat Valves” is off in the global Default Permissions, non-group users simply never see the Valves panel or the per-tool toggles in Integrations; flip the same switch for a user-group and every member of that group inherits the same blindness, but anyone with the Admin role is immune—admins always keep full Valve access no matter how the permission is set at either the default or group level, so the only way an admin can “lose” the controls is by being demoted to a regular user and, at the same time, falling under a group (or the global default) that has the right disabled.**
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @hectorc98 on GitHub (Oct 17, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/18392
Check Existing Issues
Problem Description
Currently, the
toolIdsfield in model configuration only sets default tools that are pre-enabled when a user selects a model. However, users can still manually enable/disable any available tool through the Integrations menu during a chat session. This creates a challenge for administrators who want to:Current Behavior
toolIdsin Model Editor (Workspace → Models → Edit)toolIdsare enabled by defaultDesired Solution you'd like
Add a model-specific tool restriction capability that allows administrators to control which tools can be used with each model, not just which are enabled by default.
Preferred Implementation:
Add a
restrict_toolsboolean capability to the model configuration (similar to existingvision,file_upload, etc.). When enabled:toolIdsarray can be toggled onUI Changes:
Backend Enforcement:
utils/middleware.pybefore processing chat requestsBackward Compatibility:
restrict_tools: falsemaintains current behaviorAlternatives Considered
Alternatives Considered
1. Tool-level Access Control Only
access_controlon tools to restrict by user/group2. Remove Tools from Workspace
3. Add
allowedToolIdsordisabledToolIdsArray4. Capability-level Restrictions Instead of Tool-level
capabilities.tools: false5. Custom Pipeline/Filter
Additional Context
Real-World Use Cases:
Security Compliance: Organization wants to prevent web search and HTTP tools from being used with models that process PII/confidential data, while allowing them for general-purpose models
Cost Management: Expensive MCP servers should only be available with premium models, not with standard models
Model Limitations: Some smaller/faster models don't support tool calling well and should have tools disabled entirely
Regulatory Requirements: Healthcare/financial organizations need to enforce which external services can be called based on data classification
User Expectations:
Many admins assume that configuring tools in the Model Editor restricts usage to those tools, similar to how capabilities work. The current behavior where it's only a "default" is surprising and reduces trust in the admin interface.
Similar Features:
Open WebUI already has similar restriction patterns:
capabilities.vision: falseprevents image uploads for that modelcapabilities.file_upload: falsedisables file inputs@silentoplayz commented on GitHub (Oct 17, 2025):
Not sure if any of this info is helpful, but this is mostly based on my testing and to hopefully be informative.
If you toggle off
Allow Chat Valvesas a Default Permission in Open WebUI from your superadmin account, users OUTSIDE of any usergroup will no longer see the tools/valves controls for tools in theIntegrationsmenu orValveswithin theChat Controlssidebar.You and other admins of your Open WebUI instance are unaffected by
Default Permissions, so you and other admins will still see the tools/valves controls for tools in theIntegrationsmenu orValveswithin theChat Controlssidebar.If you toggle off
Allow Chat Valvesfor both the Default Permission and a user-group permission with the admin in aforementioned user-group, the admin will still have access to the tools/valves controls for tools in theIntegrationsmenu andValveswithin theChat Controlssidebar, also unaffected by the toggled state of theAllow Chat Valvespermission in the user-group, as theAdminrole bypasses this.Proof:
Default Permissions:
2
Adminaccounts -G30is my superadmin account,Ollamawas promoted toAdminfor the sake of this exampleA new user-group was created for both admins with the
Allow Chat Valvestoggled offThe
OllamaAdmin account still has full access to Chat Valves in this scenarioIf I change the
Ollamauser from anAdminback to aUserrole in the user-group I have it in... I can see tools withValvesaccess in theIntegrationsmenu, but not theValvescollapsible section in the Chat Controls sidebar.Lastly, if I remove the
Ollamauser from the user-group I had it in, then I can no longer see the tools/valves controls for tools in theIntegrationsmenu orValveswithin theChat Controlssidebar, as expected, because theAllow Chat Valvespermission has been toggled off this entire time (This loops us back to where we started from).TL;DR
If “Allow Chat Valves” is off in the global Default Permissions, non-group users simply never see the Valves panel or the per-tool toggles in Integrations; flip the same switch for a user-group and every member of that group inherits the same blindness, but anyone with the Admin role is immune—admins always keep full Valve access no matter how the permission is set at either the default or group level, so the only way an admin can “lose” the controls is by being demoted to a regular user and, at the same time, falling under a group (or the global default) that has the right disabled.