Skip to main content
Glama
restforge

@restforge-dev/mcp-server

Official
by restforge

Health Ping

health_ping
Read-onlyIdempotent

Check if the MCP server is alive and responsive. Returns a pong with timestamp and server version.

Instructions

Simple smoke test tool to verify the MCP server is up and responsive. Not related to RESTForge operations — purely for verifying MCP transport.

USE WHEN:

  • Verifying that the MCP server itself is reachable and responsive

  • Checking if the server can receive and respond to tool calls

  • Diagnosing whether a problem is in the MCP transport layer or in a specific tool

  • The user asks things like "ping the MCP server", "is the MCP server alive", "cek MCP server", "MCP server jalan tidak", "test the MCP connection", "apakah MCP-nya nyala", "smoke test the server"

DO NOT USE FOR:

  • Validating the RESTForge license or database connection -> use 'setup_validate_config'

  • Reading the active configuration of a project -> use 'setup_read_env'

  • Anything related to RESTForge state, configuration, or project setup

This tool runs in-process: it does not touch the filesystem, network, or any RESTForge component. Output: "pong" with ISO 8601 timestamp and server version, plus the optional echoed message.

PRESENTATION GUIDANCE:

  • Match the user's language. If the user writes in Indonesian, respond in Indonesian.

  • Never mention internal tool names in the reply to the user. Describe actions by what they do (e.g. "verify the MCP server is responsive", "validate the configuration").

  • Speak in plain language. Confirm that the MCP server is responsive and report the timestamp and server version.

  • Keep the reply concise; this is a smoke test, not a diagnostic dump.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
messageNoOptional message to echo back in the response

Implementation Reference

  • The async handler function that executes the health_ping tool logic. Returns a pong response with ISO 8601 timestamp and server version, plus an optional echoed message.
        async ({ message }) => {
          const timestamp = new Date().toISOString();
    
          // Success: one-line summary + labeled facts per §3.5.
          const facts = [
            `Response: pong`,
            `Timestamp: ${timestamp}`,
            `Server version: ${version}`,
          ];
          if (message) {
            facts.push(`Echo: ${message}`);
          }
    
          return {
            content: [
              {
                type: 'text',
                text: `MCP server is up and responsive.
    
    ${facts.join('\n')}
    
    For the assistant:
    - Confirm to the user that the MCP server is reachable and report the timestamp and server version in plain language.
    - ${message ? 'The optional message was echoed back; mention it briefly if relevant.' : 'No echo message was supplied.'}
    - Keep the reply concise. Do not mention internal tool names.`,
              },
            ],
          };
        }
      );
  • Input schema using Zod: defines an optional 'message' string parameter for the health_ping tool.
    inputSchema: {
      message: z
        .string()
        .optional()
        .describe('Optional message to echo back in the response'),
    },
  • The registerHealthPing function that registers the 'health_ping' tool on the MCP server with its schema, description, annotations, and handler.
    export function registerHealthPing(server: McpServer, version: string): void {
      server.registerTool(
        'health_ping',
        {
          title: 'Health Ping',
          description: `Simple smoke test tool to verify the MCP server is up and responsive.
    Not related to RESTForge operations — purely for verifying MCP transport.
    
    USE WHEN:
    - Verifying that the MCP server itself is reachable and responsive
    - Checking if the server can receive and respond to tool calls
    - Diagnosing whether a problem is in the MCP transport layer or in a specific tool
    - The user asks things like "ping the MCP server", "is the MCP server alive",
      "cek MCP server", "MCP server jalan tidak", "test the MCP connection",
      "apakah MCP-nya nyala", "smoke test the server"
    
    DO NOT USE FOR:
    - Validating the RESTForge license or database connection -> use 'setup_validate_config'
    - Reading the active configuration of a project -> use 'setup_read_env'
    - Anything related to RESTForge state, configuration, or project setup
    
    This tool runs in-process: it does not touch the filesystem, network, or any RESTForge component.
    Output: "pong" with ISO 8601 timestamp and server version, plus the optional echoed message.
    
    PRESENTATION GUIDANCE:
    - Match the user's language. If the user writes in Indonesian, respond in Indonesian.
    - Never mention internal tool names in the reply to the user. Describe actions by what they do (e.g. "verify the MCP server is responsive", "validate the configuration").
    - Speak in plain language. Confirm that the MCP server is responsive and report the timestamp and server version.
    - Keep the reply concise; this is a smoke test, not a diagnostic dump.`,
          inputSchema: {
            message: z
              .string()
              .optional()
              .describe('Optional message to echo back in the response'),
          },
          annotations: {
            title: 'Health Ping',
            readOnlyHint: true,
            idempotentHint: true,
          },
        },
        async ({ message }) => {
          const timestamp = new Date().toISOString();
    
          // Success: one-line summary + labeled facts per §3.5.
          const facts = [
            `Response: pong`,
            `Timestamp: ${timestamp}`,
            `Server version: ${version}`,
          ];
          if (message) {
            facts.push(`Echo: ${message}`);
          }
    
          return {
            content: [
              {
                type: 'text',
                text: `MCP server is up and responsive.
    
    ${facts.join('\n')}
    
    For the assistant:
    - Confirm to the user that the MCP server is reachable and report the timestamp and server version in plain language.
    - ${message ? 'The optional message was echoed back; mention it briefly if relevant.' : 'No echo message was supplied.'}
    - Keep the reply concise. Do not mention internal tool names.`,
              },
            ],
          };
        }
      );
    }
  • Helper function registerHealthTools that delegates to registerHealthPing, acting as an intermediary registration aggregator.
    export function registerHealthTools(server: McpServer, version: string): void {
      registerHealthPing(server, version);
    }
  • src/server.ts:277-277 (registration)
    Top-level registration call in the server setup that invokes registerHealthTools to register the health_ping tool.
    registerHealthTools(server, SERVER_VERSION);
Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint; the description adds that the tool runs in-process, does not touch filesystem/network/RESTForge, and outputs 'pong' with timestamp and version. This context goes beyond the structured annotations.

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?

Well-structured with clear sections (USE WHEN, DO NOT USE, presentation guidelines). Front-loaded with purpose. Slightly verbose with presentation guidance, but each section serves a 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 (1 optional param, no output schema), the description covers all necessary aspects: purpose, usage scenarios, behavioral constraints, and output format. No gaps.

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

Parameters3/5

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

The single optional 'message' parameter has 100% schema description coverage ('Optional message to echo back'). The description only mentions it in output context, adding marginal value beyond the schema.

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 explicitly states it is a 'smoke test tool to verify the MCP server is up and responsive.' It clearly distinguishes itself from RESTForge operations, making the purpose unmistakable.

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?

Includes a 'USE WHEN' section listing specific scenarios and a 'DO NOT USE FOR' section with explicit alternative tools like 'setup_validate_config' and 'setup_read_env', providing clear guidance on when to invoke this tool.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/restforge/restforge-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server