A
licenseC
qualityD
maintenanceA simple MCP server that provides a basic greeting tool for saying hello with customizable names. Serves as a boilerplate template for developers to quickly create and deploy new MCP servers.
1
4 npm
MIT
hc0061365-mcp-hello-world
by hc0061365
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@hc0061365-mcp-hello-worldSay hello to John"
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
A simple MCP (Model Context Protocol) server that provides hello world greeting tools.
工具列表 | Tools
工具名称 | 描述 |
| 向某人问好，返回友好的问候消息 |
| 同时向多人问好 |
Related MCP server: mcpv3e
前置需求 | Prerequisites
Node.js 22 或以上版本
开始使用 | Getting Started
使用 Stdio 启动 | Start with Stdio transport
在 MCP 客户端配置中添加以下内容：
{
"mcpServers": {
"hc0061365-mcp-hello-world": {
"command": "npx",
"args": ["hc0061365-mcp-hello-world@latest"]
}
}
}本地开发 | Local Development
# 安装依赖
npm install
# 使用 MCP Inspector 测试
npx @modelcontextprotocol/inspector node src/index.jsMCP 客户端配置 | MCP Client Configuration
Claude Desktop
编辑 ~/.claude/claude_desktop_config.json:
{
"mcpServers": {
"hc0061365-mcp-hello-world": {
"command": "node",
"args": ["/path/to/hc0061365-mcp-hello-world/src/index.js"]
}
}
}Cursor
编辑 ~/.cursor/mcp.json:
{
"mcpServers": {
"hc0061365-mcp-hello-world": {
"command": "node",
"args": ["/path/to/hc0061365-mcp-hello-world/src/index.js"]
}
}
}VS Code
在工作区 .vscode/mcp.json 中添加：
{
"mcpServers": {
"mcp-hello-world": {
"command": "node",
"args": ["${workspaceFolder}/src/index.js"]
}
}
}License
MIT
Available Tools
2 toolsgreet_multipleC
Greet multiple people at once.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes |
TDQS
C2.8/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 behavioral burden. It does not disclose what the greeting returns, whether each name is validated or errors are raised for bad input, or whether greeting has any side effect beyond echoing text.
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?
A single short sentence with the key information front-loaded and zero filler. Brevity is appropriate for a simple tool, though trimming leaves nothing that explains the parameter.
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?
The tool is trivial and has no output schema, and the description conveys the basic operation. Still, with no annotations and 0% parameter coverage, it omits input constraints and any return behavior an agent might need to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single 'names' parameter, so the description must compensate — but it says only 'multiple people', adding no constraints, format, ordering, or duplicate-handling semantics for the string array beyond what the type already implies.
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?
States a clear verb ('greet') and resource ('multiple people'), which implicitly contrasts with the sibling 'hello' (singular greeting). However, it never names or explicitly distinguishes itself from 'hello', so an agent must infer the plurality difference rather than read it.
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?
No when-to-use or when-not-to-use guidance is given. There is no explicit statement like 'use this instead of hello when greeting more than one person', so routing between the two siblings is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
helloB
Say hello to someone. Returns a friendly greeting message.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | World |
TDQS
B3/5.0
Behavior3/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 does disclose the behavioral outcome (returns a friendly greeting message), but says nothing about whether it has side effects, needs any permissions, or how failures are handled.
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?
Two short sentences, front-loaded with the action and with no filler. Slightly more verbose than strictly necessary for such a trivial tool, but every sentence carries 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?
For a one-optional-parameter tool with no output schema, the description covers purpose and return adequately. It stops short of explaining the parameter's default or the relationship to the sibling tool, leaving minor but real gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate – but it only obliquely implies the 'name' parameter via 'to someone'. The documented default of 'World' and what happens when the argument is omitted are not explained anywhere.
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 states a specific verb (say hello) and resource (someone) plus the return value (a friendly greeting message). It is clear on its own, though it never explicitly distinguishes itself from the sibling greet_multiple beyond the implicit singular 'someone'.
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?
There is no statement of when to use this tool versus greet_multiple, which is the obvious alternative for greeting multiple people. The agent is left to infer the selection rule from the name alone.
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.
2 tool updates
v1.0.0- First observed
greet_multiple - First observed
hello
TDQS
B3.1/5.0
Scored across 2 tools
Disambiguation4/5
hello targets a single recipient while greet_multiple targets multiple recipients, so the cardinality difference provides some distinction. However, greet_multiple is essentially a batch version of hello, creating overlap if an agent could simply call hello repeatedly.
Naming Consistency3/5
hello is a bare greeting word while greet_multiple follows a verb+quantifier pattern; both are lowercase snake_case but do not follow a consistent verb_noun convention. The mixed structure is readable but not predictable.
Tool Count3/5
Only two tools exist, which feels thin even for a hello-world server. The second tool is a minor variant rather than a distinct capability, so the set is borderline under-scoped.
Completeness4/5
The greeting domain is covered for single and multiple recipients, but there is no customization (e.g., formal/informal tone) or additional greeting lifecycle operations. These are minor gaps that an agent can work around.
Maintenance
ActivityInactive
ResponsivenessNo issues
Related MCP Connectors
POC MCP server. Tool say_hello returns 'Welcome' (agent -> MCP -> API path).
A very simple remote MCP server that greets you, with a custom icon.
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceMCP server providing greeting and echo tools for testing and demonstration.-
- FlicenseAqualityDmaintenanceA simple local MCP server that provides greeting and integer addition tools.2-
- AlicenseNot gradedqualityDmaintenanceMCP server that provides a greeting tool to say hello to users.MIT