Skip to main content
Glama
hawx1993

antd-weather-mcp

by hawx1993
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

ant-design GitHub MCP Demo

一个最简单的 TypeScript MCP Server，通过 GitHub REST API 实时读取 ant-design/ant-design。

安装和运行

npm install
npm run build
npm start

可选：设置 GITHUB_TOKEN，提高 GitHub API 的请求额度：

GITHUB_TOKEN=ghp_xxx npm start

提供 3 个 MCP tools：

  • get_repository：读取仓库信息

  • list_directory：读取目录列表

  • read_file：读取文本文件

每次工具调用都会请求 GitHub API，因此不是本地 clone 的静态副本。

Related MCP server: Weather MCP Server

直接运行演示

如果暂时没有接入 MCP 客户端，可以直接运行命令行 Demo。它会实时读取仓库信息、根目录和 package.json：

npm run demo

演示代码位于 src/demo.ts，与 MCP Server 共用 GitHub 请求逻辑。

AI Agent + MCP 完整演示

真正的 Agent 演示位于 src/agent.ts。它会：

  1. 启动当前 MCP Server

  2. 通过 MCP Client 发现 Server 暴露的 tools

  3. 把 tools 提供给 OpenAI 模型

  4. 模型自主决定调用哪个 MCP tool

  5. Agent 通过 MCP Client 执行工具，并把结果交回模型

先在项目根目录的 .env.local 中填写 DeepSeek API Key：

DEEPSEEK_API_KEY=你的_deepseek_api_key
DEEPSEEK_MODEL=deepseek-v4-flash

然后运行：

npm install
npm run build
npm run agent

也可以传入自己的问题：

npm run agent -- "读取 ant-design 的 components/button/button.tsx，并总结它的主要逻辑"

如果需要更换模型，可以修改 .env.local：

DEEPSEEK_MODEL=deepseek-v4-pro npm run agent

运行时你会看到类似链路：

Agent 已通过 MCP Client 连接 MCP Server
发现工具：get_repository, list_directory, read_file
Agent → MCP Server: list_directory({"path":"components/button"})
MCP Server → Agent: {"content":[...]}
最终回答：...

MCP 客户端配置

当前项目根目录已经提供 .mcp.json，其中同时配置了 antd-docs 和 weather。先构建项目：

npm run build

然后在这个项目根目录启动 Claude Code，它会读取根目录的 .mcp.json。如果把配置复制到其他项目，需要把 args 中的路径改成已发布的 GitHub/npm 启动命令，或者改成新的绝对路径。

注意：.mcp.json 是 Claude Code 的项目级配置；Codex 不会自动读取它。Codex 需要单独执行 codex mcp add，或配置 ~/.codex/config.toml。

构建后，将下面配置加入客户端的 MCP 配置文件，并把路径替换为本项目的绝对路径：

{
  "mcpServers": {
    "antd-github-reader": {
      "command": "node",
      "args": ["/Users/你的用户名/mcp-demo/dist/index.js"],
      "env": {
        "GITHUB_TOKEN": "可选的 GitHub Token"
      }
    }
  }
}

发布到 GitHub 并在任意项目复用

将项目推送到 GitHub 后，可以通过统一 CLI 启动两个 Server。下面的 YOUR_GITHUB_USERNAME/antd-weather-mcp 替换成你的 GitHub 仓库：

npx -y github:YOUR_GITHUB_USERNAME/antd-weather-mcp antd
npx -y github:YOUR_GITHUB_USERNAME/antd-weather-mcp weather

Codex 全局配置

将 Server 加到用户级配置后，在任意项目都可使用：

codex mcp add antd-docs -- npx -y github:YOUR_GITHUB_USERNAME/antd-weather-mcp antd
codex mcp add weather -- npx -y github:YOUR_GITHUB_USERNAME/antd-weather-mcp weather
codex mcp list

Claude Code 全局配置

使用 --scope user 将 Server 配置到用户级别：

claude mcp add --scope user antd-docs -- npx -y github:YOUR_GITHUB_USERNAME/antd-weather-mcp antd
claude mcp add --scope user weather -- npx -y github:YOUR_GITHUB_USERNAME/antd-weather-mcp weather
claude mcp list

之后在任意项目启动 Codex 或 Claude Code，都可以让 AI 查询 ant-design 文档或天气：

查一下 ant-design Button 组件的 API，并查询旧金山未来天气。

发布到 npm（可选）

如果希望命令更短、安装更稳定，可以先把 package.json 的 name 改成一个未占用的 npm 包名，然后发布：

npm login
npm publish --access public

发布后可使用：

npx -y 你的npm包名 antd
npx -y 你的npm包名 weather

例如可以让客户端调用：

读取 ant-design 仓库 components/button 目录，并打开其中的 index.tsx

开发模式

npm run dev

天气 MCP Server

参考 MCP 天气服务器 Quickstart，项目新增了独立的 src/weather.ts。它使用 stdio 提供两个 MCP 工具：

  • get_alerts：查询美国州级天气预警，例如 CA、NY

  • get_forecast：根据经纬度查询未来天气预报

编译后可以单独启动：

npm run build
npm run weather

在 Claude Desktop 或其他 MCP 客户端中加入：

{
  "mcpServers": {
    "weather": {
      "command": "node",
      "args": ["/Users/你的用户名/mcp-demo/dist/weather.js"]
    }
  }
}

Available Tools

3 tools
get_repositoryB

实时读取 ant-design/ant-design 仓库的基本信息。

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.4/5.0
Behavior2/5

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

With no annotations, the description carries the burden of behavioral disclosure. It only states '实时读取' (real-time read), which implies current data fetching, but omits details about response format, error handling, or limitations. Minimal behavioral transparency.

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 that is front-loaded with the action ('读取') and the target ('ant-design/ant-design 仓库'). It is efficient and contains no extraneous words.

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

Completeness2/5

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

The tool has no output schema and no annotations, so the description should explain what '基本情報' (basic information) includes and what the return value looks like. It remains vague, and no usage context is provided relative to sibling tools, leaving the agent uncertain about expectations.

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 tool has zero parameters, and the schema coverage is trivially 100%. Per the rubric, 0 params yields a baseline of 4. The description adds no parameter-specific information, but none is required since there are no parameters to document.

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 uses a specific verb '读取' (read) and clearly targets the ant-design/ant-design repository. It distinguishes this tool from sibling tools like read_file and list_directory by focusing on repository-level basic information rather than file contents or directory listings.

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 guidance is provided on when to use this tool compared to read_file or list_directory. The description does not mention scenarios, prerequisites, or exclusions, leaving the agent without direction for tool selection.

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

list_directoryB

实时读取 ant-design/ant-design 仓库某个目录的文件列表。

ParametersJSON Schema
NameRequiredDescriptionDefault
refNo分支、tag 或 commit SHAmaster
pathNo目录路径，例如 components/button；根目录传空字符串

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations, the description carries full responsibility for behavioral disclosure. It only mentions 'real-time reading' but does not disclose potential side effects, error behavior, access requirements, or return format. For a read operation on a directory, more context (e.g., whether it recursively lists, includes file metadata) is needed.

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?

A single, clear sentence conveys the tool's purpose without redundancy. It is appropriately sized and front-loaded with the key action and target.

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 description mentions the specific repository, which is useful context, but it lacks information about the output format (e.g., whether it returns only names or metadata), pagination, and error handling. Given there is no output schema, this gap reduces completeness slightly.

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 already provides 100% coverage with descriptions for both parameters (ref and path), so the description adds no additional meaning. The baseline of 3 is appropriate when the schema fully documents parameters.

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 reads a directory file list from a specific repository (ant-design/ant-design), with a specific verb ('读取') and resource ('文件列表'). It distinguishes from siblings like read_file (which reads file contents) and get_repository (which likely retrieves repository metadata).

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 guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description simply states what it does without contextualizing its use among sibling tools.

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

read_fileA

实时读取 ant-design/ant-design 仓库中的文本文件内容。

ParametersJSON Schema
NameRequiredDescriptionDefault
refNo分支、tag 或 commit SHAmaster
pathYes文件路径，例如 components/button/button.tsx

TDQS

A3.8/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 burden. It adds the qualifiers 'real-time' and 'text file', indicating the tool fetches live content and only supports text files. However, it does not disclose return format, error behavior, or any limitations beyond text-only.

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, compact sentence that immediately states the tool's purpose. It is front-loaded and contains no wasted words.

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 file-reading tool with a fully described schema, this description is largely complete. It would benefit from explicitly stating the return value (file content) and handling of binary files, but the 'text file content' wording partially covers this.

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% since both 'path' and 'ref' have descriptions in the input schema. The tool description itself does not add extra parameter meaning, matching the baseline 3 for high schema coverage.

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 reads text file content from the ant-design/ant-design repository, providing a specific verb and resource. It distinguishes from siblings (list_directory, get_repository) by focusing on content retrieval rather than directory listing or repo metadata.

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 via its purpose—if you need file content, use read_file—but it does not explicitly mention when to use it over alternatives like list_directory. No exclusions or alternative tool references are provided.

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.

  1. 3 tool updatesv1.0.0
    • First observedget_repository
    • First observedlist_directory
    • First observedread_file
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored across 3 tools

Disambiguation5/5

Each tool targets a distinct resource: read_file for file contents, get_repository for repo metadata, and list_directory for directory listings. There is no overlap or ambiguity among them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: read_file, get_repository, list_directory. This makes the set predictable and easy to navigate.

Tool Count5/5

With only 3 tools, the server is tightly scoped to read-only repository access. Each tool serves a distinct, necessary purpose and the count is appropriate for this narrow domain.

Completeness5/5

The tool set covers the core read operations for a repository: listing directories, reading files, and fetching repository metadata. There are no obvious gaps within the intended scope.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers