Skip to main content
Glama
olgasafonova

productplan-mcp-server

by olgasafonova
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

health_check

Read-only

Check MCP server health and cache stats to diagnose issues or monitor rate limits. Optionally verify API connectivity with deep mode for thorough status checks.

Instructions

Check MCP server health and cache stats.

USE WHEN: "Server status", "Rate limits", "Diagnose issues" For API connectivity only, use check_status instead. FAILS WHEN: deep=true and API is unreachable. Basic health (deep=false) always succeeds if server is running.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
deepNoAlso verify API connectivity (~500ms)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesThe ProductPlan payload (object or array) returned by the API, passed through verbatim
summaryYesHuman-readable summary of the result (e.g. "Found 3 roadmaps")

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv6.0.0
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "data": {
+      "description": "The ProductPlan payload (object or array) returned by the API, passed through verbatim",
+      "type": "object"
+    },
+    "summary": {
+      "description": "Human-readable summary of the result (e.g. \"Found 3 roadmaps\")",
+      "type": "string"
+    }
+  },
+  "required": [
+    "summary",
+    "data"
+  ],
+  "type": "object"
+}
  2. First observedv5.0.0

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, and the description adds failure conditions (FAILS WHEN deep=true and API is unreachable) and clarifies that basic health always succeeds when the server runs. This provides behavioral context beyond annotations, though it does not detail the return format (mitigated by an output schema being present).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and uses labeled sections (USE WHEN, FAILS WHEN) to structure information efficiently. It is slightly longer than the minimal two-sentence example but every sentence adds value and is well front-loaded with the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one optional parameter), the presence of an output schema, and annotations covering read-only behavior, the description is complete. It covers when to use, when not to use, failure modes, and the difference from the sibling tool, leaving nothing critical unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes the deep parameter at 100% coverage, but the description adds the failure condition tied to deep=true, which enriches the parameter's semantics. This goes beyond the schema's 'Also verify API connectivity (~500ms)' by specifying the consequence of that verification.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Check' and the resource 'MCP server health and cache stats', making the tool's purpose unmistakable. It also explicitly differentiates from the sibling check_status by noting that check_status is for API connectivity only, so an agent can distinguish between them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit USE WHEN scenarios ('Server status', 'Rate limits', 'Diagnose issues') and gives a direct alternative ('For API connectivity only, use check_status instead'). This leaves no ambiguity about when to select this tool over its sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools