[Bug]: Toggling a `resource` makes it invisible

[gabe-l-hart]

🐞 Bug Summary

When calling the /resources/{resource_id}/toggle endpoint with activate=False, the result is success. After this, the resources does not show up in subsequent GET /resources calls, so it is not visible at all in its disabled state. It CAN be re-enabled by calling toggle again with activate=True, after which it does show up in GET /resources again.

Related Item #1: When doing GET /resources/{resource_id}, the is_active field is not returned, so the only way to poll the current active status is to list all resources and look for one that matches the ID.

Related Item #2: For resources, prompts, and tools, the name of the field is is_active/isActive whereas for gateways/servers, the name of the field is enabled (I haven't checked a2a).

Related Item #3: When calling /toggle on any type, it does not actually "toggle" (switch the state from the current state), but instead simply sets the enabled/is_active bool to whatever the activate param is set to. This defaults to True, so calling /toggle without explicitly setting activate will always enable the object.

This same bug likely also effects prompts and tools, but I haven't verified yet.

---

🧩 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)

[gabe-l-hart]

Confirmed that this is also true for prompts.

[gabe-l-hart]

For tools (also a federated resource-type), there are several more inconsistencies with the other federated resource-types (resources and prompts):

• The status field is enabled rather than is_active
• The enabled value IS returned with GET /tools/{tool_id}, so you don't need to list-and-search
• The tool_id is a UUID (str) rather than an int.

[gabe-l-hart]

The original issue of the resources becoming invisible may have been incorrect since I believe they may have been hidden behind the "include_inactive" query param

[rwhitnah]

Also, the list version of Resources (in the API) appears to have isActive always true, even for inactive resources. I think it only updates in the HTML version.

[rakdutta]

@gabe-l-hart

"Related Item #1: When doing GET /resources/{resource_id}, the is_active field is not returned, so the only way to poll the current active status is to list all resources and look for one that matches the ID."

=>>The current implementation returns only active resources, which is why the is_active field is not included in the response. If a resource exists but is inactive, the API instead returns an error message:
"detail": "Resource '101' exists but is inactive".

"Related Item #3: When calling /toggle on any type, it does not actually "toggle" (switch the state from the current state), but instead simply sets the enabled/is_active bool to whatever the activate param is set to. This defaults to True, so calling /toggle without explicitly setting activate will always enable the object."
=>> A pull request has been raised to address this behavior: #1504

"Related Item #2: For resources, prompts, and tools, the name of the field is is_active/isActive whereas for gateways/servers, the name of the field is enabled (I haven't checked a2a).'
==>We are creating a separate issue to address these naming inconsistencies, along with introducing UUID support for prompts and resources. #1505