Offers a Web API built on Express that handles frontend queries and delivers streaming responses with process visualization
Provides a tool for querying GitHub user information, allowing access to profile data through the GitHub API
Serves as the foundation for the MCP server implementation, enabling tool registration and execution
Used for implementing both the MCP server and client components with type safety
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-Server what's the weather in Tokyo tomorrow?"
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-Server 是一个基于 Model Context Protocol (MCP) 的服务端和客户端实现，允许大语言模型（LLM）通过结构化协议调用外部工具完成复杂任务。项目主要包含两部分：MCP服务端和TypeScript实现的客户端。
Related MCP server: MCP Server For Local
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ 前端应用 │────▶│ MCP 客户端 │────▶│ MCP 服务端 │
└───────────────┘ └───────────────┘ └───────────────┘
△ │ │
│ ▼ ▼
│ ┌───────────────┐ ┌───────────────┐
└───────────│ 大语言模型 │ │ 外部服务 API │
│ (Deepseek) │ │ (天气、GitHub)│
└───────────────┘ └───────────────┘服务端是工具的提供者，负责注册和执行各种工具。
主要功能：
工具注册：目前已实现天气预报查询和GitHub用户信息查询工具
工具执行：接收客户端请求，执行相应工具并返回结果
通信：通过标准输入输出(stdio)与客户端通信
客户端连接大语言模型API和MCP服务端，负责处理用户查询并协调模型调用和工具调用。
主要功能：
连接MCP服务端并获取可用工具列表
与大语言模型API通信（默认使用Deepseek）
解析模型输出中的工具调用请求
协调工具调用流程并汇总结果
提供命令行交互界面
提供基于Express的Web API
客户端提供了HTTP接口供前端应用调用，支持流式输出和过程可视化。
主要端点：
/sse: 处理前端查询请求，返回包含思考过程和结果的流式响应
客户端实现了白盒过程展示，让用户可以看到：
意图识别过程
工具选择过程
工具调用参数和结果
最终答案生成过程
后端：Node.js、TypeScript
框架：Express
大语言模型：Deepseek (通过OpenAI兼容API)
通信协议：Model Context Protocol
SDK：@modelcontextprotocol/sdk
启动服务端：
node dist/src/index.js启动客户端并连接到服务端：
node dist/mcp-client-typescript/src/index.js /path/to/server/script.js访问Web API：
POST http://localhost:3000/sse
Content-Type: application/json
{
"query": "北京今天的天气怎么样？"
}需要在.env文件中设置以下环境变量：
LLM_API_KEY: Deepseek API密钥
GAODE_KEY: 高德地图API密钥（用于天气查询）
用户发送查询到客户端
客户端将查询发送给大语言模型
大语言模型分析查询并决定是否需要调用工具
如需调用工具，客户端通过MCP协议向服务端发送请求
服务端执行工具并返回结果
客户端将工具结果再次发送给大语言模型生成最终回答
将回答返回给用户
MCP-Server项目提供了一个完整的大语言模型工具调用示例实现，展示了如何通过结构化协议让模型访问外部工具和服务，增强模型的能力边界。通过白盒过程可视化，用户可以更好地理解模型的思考过程和工具调用逻辑。
根据用户名获取 Github 用户信息
| Name | Required | Description | Default |
|---|---|---|---|
| username | No |
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. The description only states what the tool does ('get Github user information') without adding any behavioral traits like whether it requires authentication, has rate limits, returns specific error codes, or what the output format might be. This leaves significant gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence in Chinese that directly states the tool's function without any unnecessary words. It's front-loaded with the core purpose and efficiently conveys the essential information in minimal space, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no annotations, no output schema), the description is incomplete. It lacks details on behavioral aspects (e.g., authentication, error handling) and output expectations, which are crucial for an AI agent to use the tool correctly. While the purpose is clear, the overall context needed for effective tool invocation is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter ('username') with 0% description coverage, meaning the schema provides no semantic details. The description implies the parameter's purpose ('根据用户名' means 'based on username'), adding some meaning beyond the bare schema. However, it doesn't specify format constraints (e.g., case sensitivity, valid characters) or examples, so it only partially compensates for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '根据用户名获取 Github 用户信息' translates to 'Get Github user information based on username.' This specifies both the verb ('get') and resource ('Github user information'), making the purpose unambiguous. However, it doesn't differentiate from the sibling tool 'get-weather-forecast' since they operate on completely different domains, so sibling differentiation isn't relevant here.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 prerequisites, constraints, or scenarios where this tool is preferred over other methods. While the sibling tool is unrelated (weather vs. GitHub), there's still no usage context provided, such as rate limits or authentication needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据经纬度获取天气信息
| Name | Required | Description | Default |
|---|---|---|---|
| city | No |
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 what the tool does but doesn't describe how it behaves: no information on error handling, rate limits, authentication needs, data freshness, or what happens if inputs are invalid. The description is minimal and doesn't compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a single sentence in Chinese. It's front-loaded with the core purpose and has no wasted words. However, it might be overly brief given the tool's complexity and parameter issues, but as a standalone statement, it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and low schema description coverage (0%), the description is incomplete. It doesn't explain the return values, error conditions, or clarify the parameter mismatch. For a tool with one parameter and potential ambiguity, more context is needed to make it fully usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions '经纬度' (latitude and longitude) as the expected input, but the input schema only has a 'city' parameter of type string with 0% schema description coverage. This creates a contradiction: the description implies coordinates are needed, while the schema suggests a city name. The description doesn't clarify this discrepancy or add meaningful semantics beyond what's implied, failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '根据经纬度获取天气信息' (Get weather information based on latitude and longitude). It uses a specific verb ('获取' - get) and resource ('天气信息' - weather information). However, it doesn't distinguish from the sibling tool 'get-github-user', which is unrelated, so differentiation isn't needed here.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 prerequisites, constraints, or comparison with other weather-related tools (though none are listed as siblings). The usage is implied from the purpose but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get-github-userget-weather-forecastScored across 2 tools
The two tools have completely distinct purposes with no overlap: one retrieves GitHub user information based on a username, while the other fetches weather forecasts based on geographic coordinates. An agent would have no difficulty telling these tools apart as they operate in entirely different domains.
Both tools follow a consistent verb-noun naming pattern (get-github-user and get-weather-forecast), using hyphens for separation. The naming is predictable and readable throughout the set.
With only 2 tools, the server feels thin and under-scoped for a general-purpose 'MCP-Server' name. The tools cover unrelated domains (GitHub and weather), suggesting a lack of cohesive focus rather than a well-defined purpose that justifies such a minimal set.
The tool surface is severely incomplete for any coherent domain. As a GitHub tool, it lacks basic operations like listing repos or issues; as a weather service, it misses features like historical data or alerts. The two tools together don't form a complete workflow for any identifiable purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol (MCP) application for automated GitHub PR analysis and issue management.…
A Model Context Protocol server for Wix AI tools
Stateless agentic tools over MCP: concept extraction, long-context, knowledge graph, planning.
