Check PGroonga health status and detect unavailable diagnostics to identify search issues before they affect queries.
Report limited PGroonga health checks and explicitly unavailable diagnostics.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| writable | Yes | ||
| walStatus | Yes | ||
| unavailable | Yes | ||
| laggedIndexes | Yes | ||
| extensionAvailable | Yes | ||
| potentiallyBrokenIndexes | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It does reveal that the tool reports limited checks and explicitly indicates unavailable diagnostics, which is a useful behavioral trait. However, it omits details about error handling, response semantics, and what specific checks are performed, leaving gaps that the output schema may only partially fill.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no redundant wording. It front-loads the action and scope, making it easy to parse and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters and an output schema is present, the description is sufficiently complete for an agent to select the tool. The vagueness of 'limited' is mitigated by the output schema, which likely documents the exact fields and behavior. It does not explain return values, but the output schema covers that responsibility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so parameter semantics are not applicable. The baseline for zero parameters is 4, and the description does not need to add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Report' and clearly identifies the resource as PGroonga health checks. The mention of 'limited' and 'explicitly unavailable diagnostics' adds scope and distinguishes it from sibling tools that handle search, indexing, or normalization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention exclusions or when not to use it, and there is no reference to sibling tools or conditions for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.