Implement a Tool Health Check Endpoint and Status Metadata

[rgeissen]

Is your feature request related to a problem? Please describe.
I'm always frustrated when the agent wastes time and resources repeatedly attempting to execute a tool that is fundamentally broken on the server side. The agent currently only discovers a non-functional tool at runtime, after the user has already initiated a plan. In the provided execution log, the qlty_rowsWithMissingValues tool fails for every single column across four different tables because its underlying database function does not exist. This results in dozens of failed, logged API calls, which delays the final answer and gives a poor impression of the system's intelligence.

Describe the solution you'd like
I would like the MCP server to provide a mechanism for clients to proactively determine the operational status of its tools before attempting to execute them. This could be implemented in two ways, ideally together:

1. Status in Tool Definitions: The response from list_tools should include a status field (e.g., OPERATIONAL, DEPRECATED, NON_OPERATIONAL) for each tool. This allows the client to filter out or deprioritize broken tools when presenting them in the UI or when the LLM is selecting a tool.
2. Dedicated Health Check Endpoint: A specific endpoint (e.g., /status or /health) should be available that returns a list of all tools and their current operational status. This would be useful for system monitoring and for clients to perform a quick health check on startup.

This would allow the agent to gracefully inform the user or the LLM that a certain capability is unavailable from the very beginning of a plan.

Describe alternatives you've considered
The primary alternative is the current client-side fix, where the agent discovers a broken tool at runtime and adds it to a session-specific blacklist (self.globally_failed_tools). While this prevents the tool from being called again within the same session, it is inefficient because it requires at least one failed API call to discover the problem. This "solution" does not persist, meaning every new session or new client instance will have to re-discover the same broken tool, which is a wasteful process.

Additional context
The execution log shows the repeated error: [Error 5589] Function 'TD_getRowsWithMissingValues' does not exist. This is a clear server-side configuration or deployment issue that a client cannot fix. A server-provided health status would prevent the agent from ever attempting to call this tool, leading to a much cleaner, faster, and more intelligent execution path.

[remi-td]

Well, if a tool fails because of a missing method or data structure on the server side, this should be detected by the testing framework, not at runtime (or startup), and fixed before release.

I agree that this should be be done, please have a look at the testing part @rgeissen and recommend how we could implement if not already in place. I would vote for adding a loop testing all tools and collecting the error messages (additionally to the current LLM-based testing).

What would make sense at runtime (or startup) would be testing the custom tools that may depend on business data structure on the platform that may evolve independently from the MCP server. Today there is little capability to test or debug these tools, so this should be addressed. We need to find an efficient solution for this (eg. testing all tools at startup may be too much overhead). We should open a separate issue for this one.