How do I use MCP Hello World?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Hello World test the connection to make sure it's working" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

MCP Hello World

by MillCityAI

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

MCP Hello World

A minimal MCP (Model Context Protocol) server that responds with "Hello, World" via Streamable HTTP. This project serves as a reference implementation and integration testing baseline for MCP client development.

Features

Streamable HTTP MCP endpoint at /mcp that returns "Hello, World"
Health check endpoint at /healthz for monitoring
Prometheus metrics at /metrics for observability
Production-ready with proper error handling, logging, and security
TypeScript codebase with comprehensive test coverage
Docker support for containerized deployment
Cloud Run ready for serverless deployment

Related MCP server: Streamable HTTP MCP Server

Quick Start

Prerequisites

Node.js 20+
npm or yarn

Local Development

Install dependencies
```
npm install
```
Start development server
```
npm run dev
```

Test the endpoints

# Health check
curl http://localhost:8080/healthz

# Metrics
curl http://localhost:8080/metrics

# MCP endpoint (POST request)
curl -X POST http://localhost:8080/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"initialize","id":1}'

Using with MCP Inspector

The primary use case is connecting via MCP Inspector for integration testing:

Deploy or run locally (see deployment options below)
Open MCP Inspector in your browser
Connect to your MCP server
- Local development: http://localhost:8080/mcp
- Cloud Run: https://your-service-url.run.app/mcp
Verify connection
- You should see "Hello, World" message
- Connection status should show as connected
- Response time should be < 300ms (excluding cold starts)

API Endpoints

`POST /mcp` - MCP Streamable HTTP

Main MCP endpoint that implements the Streamable HTTP protocol.

Request:

{
  "jsonrpc": "2.0", 
  "method": "initialize",
  "id": 1
}

Response: Server-Sent Events stream

data: {"jsonrpc":"2.0","id":1,"result":{"message":"Hello, World","timestamp":"2025-08-28T...","server":"mcp-hello-world","version":"0.1.0"}}

Headers:

Content-Type: text/event-stream
Cache-Control: no-store
Access-Control-Allow-Origin: *

`GET /healthz` - Health Check

Returns server health status and uptime.

Response:

{
  "status": "ok",
  "uptime_s": 120,
  "timestamp": "2025-08-28T...",
  "version": "0.1.0"
}

`GET /metrics` - Prometheus Metrics

Returns metrics in Prometheus text exposition format.

Key Metrics:

mcp_hello_world_http_requests_total - HTTP request counter
mcp_hello_world_handshake_total - MCP handshake counter
mcp_hello_world_handshake_duration_seconds - MCP handshake latency
mcp_hello_world_uptime_seconds - Server uptime
mcp_hello_world_cold_start_total - Cold start counter (Cloud Run)

Development

Scripts

# Development with hot reload
npm run dev

# Build for production
npm run build

# Run tests
npm test

# Run tests in watch mode
npm run test:watch

# Lint code
npm run lint

# Type check
npm run typecheck

# Docker build
npm run docker:build

# Docker run
npm run docker:run

Testing

The project has comprehensive test coverage with 38 tests covering:

Core MCP functionality - handshake, response format, error handling
HTTP endpoints - health checks, metrics, CORS
Error scenarios - malformed requests, method validation
Metrics collection - counters, histograms, gauges
Logging - structured logs, request IDs

Run tests with coverage:

npm test

Code Quality

ESLint for code linting with TypeScript rules
Prettier for code formatting
TypeScript with strict configuration
Vitest for testing with coverage reporting
Conventional Commits for commit messages

Deployment

Docker

Build the image
```
docker build -t mcp-hello-world .
```
Run the container
```
docker run -p 8080:8080 mcp-hello-world
```

Google Cloud Platform (Automated)

This project uses GCP Cloud Build for automated CI/CD. Every push to the main branch triggers:

Automated Build Pipeline (via cloudbuild.yaml):
- Code quality checks (TypeScript, ESLint)
- Test execution with coverage
- Docker image build and push to Artifact Registry
- SBOM generation and security scanning
- Automatic deployment to Cloud Run
- Health checks and endpoint testing

Setup GCP Cloud Build Trigger:

# Enable required APIs
gcloud services enable cloudbuild.googleapis.com
gcloud services enable run.googleapis.com
gcloud services enable artifactregistry.googleapis.com

# Create Artifact Registry repository
gcloud artifacts repositories create mcp-servers \
  --repository-format=docker \
  --location=us-central1

# Set up Cloud Build trigger (via Console or CLI)
gcloud alpha builds triggers create github \
  --repo-name=mcp-hello-world \
  --repo-owner=MillCityAI \
  --branch-pattern=^main$ \
  --build-config=cloudbuild.yaml

Manual Deployment (if needed):

gcloud builds submit --config cloudbuild.yaml

Get the service URL:

gcloud run services describe mcp-hello-world \
  --platform managed \
  --region us-central1 \
  --format 'value(status.url)'

Environment Variables

Variable	Required	Default	Description
`PORT`	No	8080	Server port
`NODE_ENV`	No	development	Environment (development/production)
`LOG_LEVEL`	No	info/debug	Logging level
`REGION`	No	unknown	Deployment region
`BUILD_SHA`	No	dev	Build/commit SHA
`INSTANCE_ID`	No	local	Instance identifier

Architecture

Technology Stack

Runtime: Node.js 20 LTS
Framework: Fastify (high performance HTTP server)
Language: TypeScript with strict configuration
Logging: Pino (structured JSON logging)
Metrics: prom-client (Prometheus metrics)
Testing: Vitest + @vitest/coverage-v8
Container: Multi-stage Docker build with Alpine Linux

Security

OWASP ASVS Level 1 compliance
CORS properly configured for MCP Inspector
Rate limiting (100 requests/minute)
Security headers via Helmet
Input validation and request size limits
Secrets management via environment variables
Non-root container execution
Log sanitization (redacts auth headers)

Performance

Target latency: p95 < 300ms (excluding cold starts)
Cold start tracking for Cloud Run deployments
Connection pooling and keep-alive
Efficient JSON parsing and SSE streaming
Graceful shutdown handling

Contributing

Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Make your changes with tests
Run the test suite (npm test)
Run linting (npm run lint)
Commit your changes (git commit -m 'Add amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request

License

Apache-2.0 License - see the LICENSE file for details.

Model Context Protocol - The MCP specification
MCP Inspector - MCP client testing tool
Fastify - Fast and low overhead web framework

Support

Documentation: See the /Documentation folder for detailed specs
Issues: Report bugs via GitHub Issues
Community: Join the MCP community discussions

🤖 Generated with Claude Code

Available Tools

3 tools

addB

Adds two numbers

ParametersJSON Schema

Name	Required	Description	Default
`a`	Yes	The first number
`b`	Yes	The second number

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('adds') but doesn't describe any behavioral traits such as error handling, performance characteristics, or what the output looks like. For a tool with zero annotation coverage, this is a significant gap.

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

Conciseness5/5

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

The description is extremely concise (three words) and front-loaded, with zero wasted words. Every word earns its place by directly stating the tool's purpose.

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

Completeness3/5

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

Given the tool's low complexity (simple arithmetic), high schema coverage (100%), and lack of annotations or output schema, the description is minimally adequate. It covers the basic purpose but lacks behavioral context and usage guidance, which are needed for full completeness.

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 schema description coverage is 100%, with both parameters (a and b) clearly documented in the schema. The description adds no additional meaning beyond what the schema provides, such as constraints or examples. Baseline 3 is appropriate when the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the verb ('adds') and resource ('two numbers'), making the purpose immediately understandable. It doesn't differentiate from siblings, but since the sibling tools (debug, echo) are unrelated to arithmetic operations, differentiation isn't needed for clarity.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions. The agent must infer usage solely from the tool name and description.

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

debugA

Lists all available tools and methods

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states the tool lists tools and methods, which suggests a read-only operation, but does not disclose behavioral traits such as whether it requires authentication, how it handles errors, or if it provides structured output. This leaves significant gaps in understanding the tool's behavior.

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded with the core action, making it easy to understand at a glance.

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

Completeness3/5

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

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate but lacks depth. It does not explain what the output looks like (e.g., list format, metadata) or any usage constraints, which could be helpful for an agent despite the low complexity.

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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter information, which is appropriate here. A baseline of 4 is applied as it adequately handles the lack of parameters without introducing confusion.

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 'Lists all available tools and methods' clearly states the verb ('Lists') and resource ('all available tools and methods'), making the purpose specific and unambiguous. It distinguishes itself from sibling tools 'add' and 'echo' by focusing on enumeration rather than creation or reflection.

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

Usage Guidelines3/5

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

The description implies usage for discovery or debugging contexts by mentioning 'available tools and methods', but it does not explicitly state when to use this tool versus alternatives like checking documentation or using specific tools directly. No exclusions or clear alternatives are provided.

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

echoB

Echoes back a message with 'Hello' prefix

ParametersJSON Schema

Name	Required	Description	Default
`message`	Yes	The message to echo

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'echoes back a message with 'Hello' prefix,' which implies a read-only, non-destructive operation, but it doesn't clarify aspects like error handling, performance, or side effects. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

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

Conciseness5/5

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

The description is a single, efficient sentence: 'Echoes back a message with 'Hello' prefix.' It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a simple tool. Every part of the sentence earns its place by conveying essential information.

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

Completeness3/5

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

Given the tool's low complexity (one parameter, no output schema, no annotations), the description is complete enough to understand the basic function. However, it lacks details on output format, error cases, or integration with sibling tools, which could enhance usability. It meets the minimum viable threshold but has clear gaps in contextual information.

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 input schema has 100% description coverage, with the 'message' parameter fully documented in the schema. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints. According to the rules, when schema coverage is high (>80%), the baseline score is 3, which applies here as the description doesn't compensate with extra param info.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'Echoes back a message with 'Hello' prefix.' It specifies the verb ('echoes back') and the resource ('a message'), making it easy to understand what the tool does. However, it doesn't differentiate from sibling tools like 'add' or 'debug', which could have similar communication functions, so it doesn't reach a score of 5.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'add' or 'debug'. It lacks explicit context, exclusions, or prerequisites, leaving the agent to infer usage based on the tool name and purpose alone. This minimal guidance is insufficient for optimal tool selection.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

1 tool updatev1.0.0Jan 3, 2026
- Changeddebug1 field changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
3 tool updatesAug 30, 2025
- First observedadd
- First observeddebug
- First observedecho

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: 'add' performs arithmetic, 'debug' provides system introspection, and 'echo' handles message echoing. The descriptions are straightforward, making misselection unlikely.

Naming Consistency5/5

All tool names follow a consistent, simple verb-based pattern (add, debug, echo) without any deviations in style or casing. This predictability aids in agent understanding and usage.

Tool Count3/5

With only 3 tools, the set feels thin for a general-purpose 'Hello World' server, as it lacks broader functionality typical of such demos (e.g., more operations or examples). However, it is not severely mismatched.

Completeness2/5

The tool surface is severely incomplete for a 'Hello World' domain, which often implies basic demonstrations of capabilities. There are significant gaps, such as missing operations like subtraction, logging, or more varied examples, limiting agent workflows.

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp-empty-public
io.github.brkd-h1
Minimal streamable HTTP MCP server used for owned-account registry connectivity tests.
API Testing Developer Tools
11
test-mcp B
dev.riskprofiler
An MCP server that provides a hello tool
11
staging-mcpOAuth
dev.riskprofiler
An MCP server that provides a hello tool
1
Word Of Clout ACN MCP Server
io.github.wordofclout
Guarded MCP server for agent-readable business truth, provenance, readiness, and discovery.
CRM Customer Data Platforms
2

Related MCP Servers

Echo MCP Server
Developer Tools Testing & QA Tools
piebro
A
license
C
quality
D
maintenance
A simple server implementing the Model Context Protocol (MCP) that echoes messages back, designed for testing MCP clients.
Updated a year ago (2025-04-17 16:46 UTC)
1
2
MIT
Streamable HTTP MCP Server
Command Line App Automation
rmavuluri
F
license
Not graded
quality
D
maintenance
A simple MCP server implementation that demonstrates streaming capabilities with tools for greetings and notifications, accessible through an interactive command-line client.
Updated a year ago (2025-06-07 02:38 UTC)
1
-
OpenAPI MCP Server
Developer Tools API Testing
oneWalker
A
license
Not graded
quality
D
maintenance
A server that implements the Model Context Protocol (MCP) with StreamableHTTP transport, enabling standardized interaction with model services through a RESTful API interface.
Updated a year ago (2025-07-24 14:40 UTC)
322
2
MIT
MCP Dockerized Server
App Automation Shell Access Command Line
antpavlenko
F
license
Not graded
quality
D
maintenance
A minimal, containerized MCP server that exposes a Streamable HTTP transport with API key authentication, allowing secure access to MCP endpoints.
Updated a year ago (2025-08-12 03:29 UTC)
-

Appeared in Searches

Simple HTTP server or client implementation

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/MillCityAI/mcp-hello-world'

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

MCP Hello World

Features

Quick Start

Prerequisites

Local Development

Using with MCP Inspector

API Endpoints

POST /mcp - MCP Streamable HTTP

GET /healthz - Health Check

GET /metrics - Prometheus Metrics

Development

Scripts

Testing

Code Quality

Deployment

Docker

Google Cloud Platform (Automated)

Environment Variables

Architecture

Technology Stack

Security

Performance

Contributing

License

Related Projects

Support

Available Tools

Tool Schema Changelog

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

`POST /mcp` - MCP Streamable HTTP

`GET /healthz` - Health Check

`GET /metrics` - Prometheus Metrics