[Bug]: Unique Constraint is not allowing Users to create servers/tools/resources/prompts with Names already used by another User

[MohanLaksh]

🐞 Bug Summary

Description

Currently, the database enforces a unique constraint on name fields for servers, tools, resources, and prompts.
This means that if one user creates an item named example-server, no other user can use that name, even though these objects should logically be user-scoped.

This behavior blocks multiple users from independently creating items with the same name.

🧩 Affected Component

Select the area of the project impacted:

• mcpgateway - API
• mcpgateway - UI (admin panel)
• mcpgateway.wrapper - stdio wrapper
• Federation or Transports
• CLI, Makefiles, or shell scripts
• Container setup (Docker/Podman/Compose)
• Other (explain below)

---

🔁 Steps to Reproduce

1. Log in as User A
2. Create a new server with the name test-server
3. Log in as User B
4. Attempt to create a server with the same name test-server

---

🤔 Expected Behavior

Each user should be able to create items (servers/tools/resources/prompts) with names that may already exist for other users.
The uniqueness should only be enforced per user, at team level, not globally.

The system throws a Unique Constraint Violation error, preventing creation.

Impact

Prevents multiple users from using common or descriptive names.
Reduces usability in multi-tenant scenarios.

[rakdutta]

Expected Behavior

The uniqueness should be enforced based on scope/visibility, not globally.

It should allow duplicate names in the following cases:

1. Private Level Conflict –
   Allow same (name, email, team) combination for private resources.

2. Team Level Conflict –
   Restrict duplicates within the same team.

   • If a resource with the same name already exists in a team, block creation.

3. Public Level Conflict –
   Restrict duplicates across all teams.

   • If a resource is created with public visibility, no other team should be able to use the same name.

Steps to Reproduce

1. User A creates a server vir_name with visibility = private.
2. User B tries to create a server vir_name with visibility = private in a different team.
3. Expected: Should be allowed.
   Actual: Fails with "name already exists".

Proposed Solution

• Update unique constraints across all relevant entities (gateway server, virtual server, tools, resources, and prompts) to include visibility scope (private, team, public).

• Modify validation logic consistently:

  • private: allow same name across different users/teams.
  • team: restrict within team only.
  • public: restrict globally.

Apply the same pattern to:

• gateway_servers
• virtual_servers
• tools
• resources
• prompts

---

##Example Scenario:

S.No	Name	Owner Email	Team ID	Visibility	Name Conflict as Private	Step (Team)	Name Conflict as Team	Step (Public)	Name Conflict as Public	Remarks
1	mcp-server	user1@example.com	1	Private	No	Try upgrading visibility to Team	No	Try upgrading visibility to Public	No
2	mcp-server	user1@example.com	1	Private	Yes	-	-	-	-	Conflict due to same (name, email, team)
3	mcp-server	user2@example.com	1	Private	No	Try upgrading visibility to Team	Yes	-	Already name is present for this team 1	Conflict with existing user1 record in same team
4	mcp-server	user1@example.com	2	Private	No	Try upgrading visibility to Team	No	Try upgrading visibility to Public	Yes	Conflict while upgrading to Public
5	mcp-server	user2@example.com	2	Private	No	Try upgrading visibility to Team	Yes	-	Already name is present for this team 2	Conflict with existing user1 record in same team
6	mcp-server	user1@example.com	2	Private	Yes	-	-	-	-	Conflict due to same (name, email, team)
7	mcp-server	user2@example.com	2	Private	Yes	-	-	-	-	Conflict due to same (name, email, team)

[rakdutta]

Work is on hold for prompt and resources, waiting for UI changes. Will resume afterward.

[rakdutta]

Started working on this issue for prompt, resources and a2a agent