A
licenseNot graded
qualityD
maintenanceA minimal demonstration server showcasing MCP protocol capabilities including tools, resources, and prompts with basic examples like hello world functionality.
7
MIT
mcp-demo
by AmAzing129
Click on "Install 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., "@mcp-demowhat is 123 times 456?"
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-demo
一个最小可用的 MCP (Model Context Protocol) Server 示例，使用 TypeScript SDK 编写，演示 MCP 的三大核心原语：
原语 | 示例 | 说明 |
Tools |
| 由模型调用的动作 |
Resources |
| 客户端可读取的数据（含动态资源模板） |
Prompts |
| 暴露给用户的提示词模板 |
通过 stdio 传输，可直接接入 Claude Desktop、Claude Code 或任何 MCP 客户端。
快速开始
npm install
npm run build
npm start # 启动编译后的 server
# 或开发模式
npm run devRelated MCP server: MCP Demo Server
使用 MCP Inspector 调试
npm run inspect会启动一个网页版调试器，可以交互式地调用 tools、读取 resources、预览 prompts。
接入 Claude Code
claude mcp add mcp-demo -- node /path/to/mcp-demo/dist/index.js接入 Claude Desktop
在 claude_desktop_config.json 中添加：
{
"mcpServers": {
"mcp-demo": {
"command": "node",
"args": ["/path/to/mcp-demo/dist/index.js"]
}
}
}项目结构
src/
index.ts # 全部 server 逻辑：tools / resources / prompts 注册 + stdio 启动示例交互
接入后可以试试：
“帮我算一下 123 × 456” → 触发
calculate工具“现在上海几点？” → 触发
get_current_time工具“记一条笔记 todo：明天写周报” → 触发
add_note，然后可通过note://todo资源读取
License
MIT
Available Tools
3 toolsadd_noteAdd NoteA
Save a note that can later be read via the note:// resources
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Unique note name (used in the note:// URI) | |
| content | Yes | Note content |
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It reveals the note:// URI scheme for later access but does not mention whether it overwrites, limits, or other side effects.
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?
Single sentence, front-loaded with the action, no extraneous words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description explains how the note can be retrieved (via note:// resources), providing sufficient context for an agent.
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?
Schema descriptions cover both parameters (name, content) at 100%. The tool description adds no additional parameter meaning beyond what the schema already provides.
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 action ('Save a note') and the resource ('note:// resources'), distinguishing it from sibling tools like calculate and get_current_time.
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 saving notes but provides no explicit when-to-use guidance or alternatives. Sibling tools are unrelated, so the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculateCalculatorC
Perform basic arithmetic on two numbers
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | First operand | |
| b | Yes | Second operand | |
| operation | Yes |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It fails to mention error handling (e.g., division by zero), return format, or any side effects. Only states basic arithmetic, which is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 6 words, but it is under-specific. While concise, it lacks necessary detail for a 3-parameter tool, making it merely adequate.
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 simplicity of the tool and no output schema, the description covers the basic purpose but omits edge cases, return values, and usage details needed for complete understanding.
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?
With 67% schema coverage, the description adds no additional meaning beyond the schema's property descriptions. The operation enum values are listed in schema but no further elaboration in description.
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 'Perform basic arithmetic on two numbers', which specifies the verb (perform), resource (arithmetic on two numbers), and distinguishes from sibling tools like add_note and get_current_time.
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 explicit guidance on when to use this tool vs alternatives. While the sibling tools are obviously different, the description lacks any context about usage scenarios or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_current_timeCurrent TimeA
Get the current date and time, optionally in a specific IANA timezone
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| timezone | No | IANA timezone, e.g. "Asia/Shanghai". Defaults to server timezone. |
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description only states the basic operation and doesn't disclose behavioral traits like idempotency or side effects, which is acceptable for a simple read operation but could be improved.
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 sentence with no unnecessary words, making it concise and front-loaded.
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?
For a simple tool with one optional parameter and no output schema, the description provides sufficient context for an AI agent to use it correctly.
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?
Schema coverage is 100% and the description adds little beyond the schema's description of the timezone parameter, meeting the baseline for parameter semantics.
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 tool's purpose with a specific verb 'Get' and resource 'current date and time', and distinguishes it from sibling tools like add_note and calculate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for getting current time with optional timezone but does not provide explicit guidance on when to use versus alternatives, though siblings are unrelated.
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.
3 tool updates
v0.1.0- First observed
add_note - First observed
calculate - First observed
get_current_time
TDQS
A3.7/5.0
Disambiguation5/5
Each tool serves a completely different purpose: notes, arithmetic, and time. There is no overlap or ambiguity between them.
Naming Consistency4/5
Tools follow a verb_noun pattern (add_note, get_current_time) except calculate which is a single verb. This minor inconsistency prevents a perfect score.
Tool Count5/5
Three tools is ideal for a demo server—focused and easy to understand, not too sparse or overloaded.
Completeness4/5
The tool surface covers the core actions for the demo's purpose. Note management lacks update/delete operations, but reading is handled via resources.
Maintenance
ActivityInactive
ResponsivenessNo issues
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA demonstration MCP server showcasing tools (calculator, file operations, weather, timestamp), resources (server config, system info, documentation), and reusable prompt templates for code review, documentation, and debugging.Apache 2.0
- AlicenseNot gradedqualityDmaintenanceA minimal template MCP server demonstrating basic tools, resources, and prompts functionality. Includes example implementations like a hello tool, history resource, and greet prompt for learning MCP development.7ISC
- FlicenseNot gradedqualityDmaintenanceA simple MCP server demonstrating resources, tools, and prompts, including a greeting resource, an addition tool, and a calculation prompt.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/AmAzing129/mcp-demo'
If you have feedback or need assistance with the MCP directory API, please join our Discord server