Which integrations are available for this server?

Provides semantic search and API knowledge lookup for Cocos Creator 3.8.8 engine classes and methods, enabling AI assistants to query module, class, and method information from Cocos Creator APIs.

How do I use game-knowledge MCP Server?

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., "@game-knowledge MCP Server search_api('延迟执行')" 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.

game-knowledge MCP Server

by xiachenggang

Overview Schema Source Related Servers Score Discussions Admin

JavaScript

Local

game-knowledge MCP Server

为 Cocos Creator 3.8.8 + exia-framework 提供 AI 知识库查询服务。

索引文件（index/）和 .d.ts 文件（dts/）已预构建并提交到仓库，clone 后即可直接使用。

快速安装

要求：Node.js >= 22

git clone <仓库地址> ~/exia/exia-framework-mcp
cd ~/exia/exia-framework-mcp
npm install

安装完成后无需启动，AI 编辑器会在需要时自动拉起 MCP Server。

配置 AI 编辑器

Claude Code

在游戏项目目录的 .claude/settings.json（或全局 ~/.claude/settings.json）中添加：

{
  "mcpServers": {
    "game-knowledge": {
      "command": "node",
      "args": ["/你实际clone的路径/exia-framework-mcp/src/server.js"]
    }
  }
}

配置后重启 Claude Code，运行 /mcp 命令确认 game-knowledge 状态为 connected。

Cursor

在游戏项目根目录的 .cursor/mcp.json 中添加：

{
  "mcpServers": {
    "game-knowledge": {
      "command": "node",
      "args": ["/你实际clone的路径/bit-framework-mcp/src/server.js"]
    }
  }
}

可用工具

MCP Server 启动后，AI 可直接调用以下工具查询 API：

工具	说明	示例
`search_api`	语义搜索（支持中英文互搜）	`search_api("延迟执行")`
`get_module`	查询模块包含的所有类/接口	`get_module("bit-ui")`
`get_class`	查询类的完整属性和方法	`get_class("Window")`
`get_method`	查询特定方法签名	`get_method("Window", "onShow")`

search_api 支持的 source 参数：

all（默认）：同时搜索框架和 Cocos 引擎 API
framework：只搜索 bit-framework 模块
cocos：只搜索 Cocos Creator 3.8.8 API

框架更新后同步索引（框架维护者操作）

安装 cross-env：

npm install --save-dev cross-env

普通成员不需要执行此步骤，git pull 拉取最新索引后重启编辑器即可。

# 1. 手动复制有变动的模块 .d.ts（以 exia-ccui 为例）
cp /path/to/exia-framework/exia-ccui.d.ts dts/framework/exia-ccui.d.ts

# 2. 重建索引（首次运行需下载向量模型 ~120MB，存入 models/ 目录）
npm run sync

# 3. 提交并推送（不需要提交 models/ 目录，已在 .gitignore 中）
git add dts/ index/
git commit -m "chore: 同步框架索引 vX.X.X"
git push

国内网络若下载模型超时，npm run sync 默认已启用 hf-mirror.com 镜像，也可手动指定：

HF_ENDPOINT=https://hf-mirror.com npm run sync

首次构建索引

仓库已包含预构建索引，以下步骤仅在完全重建时需要。

# 1. 放入 Cocos 3.8.8 类型定义
cp /path/to/cc.d.ts dts/cocos/cc.d.ts

# 2. 放入框架 .d.ts（每个模块一个文件）
cp /path/to/exia-ccui.d.ts      dts/framework/exia-ccui.d.ts
cp /path/to/exia-data.d.ts     dts/framework/exia-data.d.ts
# ... 其余模块同理

# 3. 构建索引（Cocos 类较多，向量化需要几分钟）
npm run sync

# 4. 提交
git add dts/ index/
git commit -m "feat: 初始化框架索引"
git push

项目结构说明

exia-framework-mcp/
├── src/
│   ├── server.js          # MCP Server 入口，定义 4 个查询工具
│   ├── searcher.js        # 索引查询逻辑（关键词 + 向量语义搜索）
│   └── build-index.js     # 索引构建脚本（解析 .d.ts → JSON + 向量）
├── dts/
│   ├── framework/         # exia-framework 各模块 .d.ts（已预置）
│   └── cocos/             # cc.d.ts（Cocos 3.8.8，已预置）
├── index/                 # 构建产物（已预置，勿手动修改）
│   ├── framework.json     # 框架类索引
│   ├── framework-vectors.json  # 框架语义向量
│   ├── cocos.json         # Cocos 类索引
│   └── cocos-vectors.json # Cocos 语义向量
├── models/                # 向量模型缓存（.gitignore，本地自动生成）
└── package.json

Available Tools

4 tools

get_classA

查询某个类或接口的完整属性和方法

ParametersJSON Schema

Name	Required	Description	Default
`className`	Yes	类名，如 Window、AssetLoader、Node

TDQS

A3.5/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 that the tool returns 'complete properties and methods', but does not disclose return format, error behavior, whether inherited members are included, or any side effects. This is a minimal disclosure with limited behavioral context.

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, front-loaded sentence that immediately conveys the tool's purpose without any filler. It is appropriately sized for a simple lookup operation.

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?

This is a simple tool with one required parameter, no output schema, and no annotations. The description states that it returns complete class/interface attributes and methods, which is adequate for basic use, but it lacks details on edge cases, scope (e.g., inherited members), and error handling, making it minimally complete rather than comprehensive.

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 describes className with examples, giving 100% coverage. The description adds the nuance '类或接口' (class or interface), slightly extending the schema's '类名', but does not otherwise provide additional parameter meaning. Baseline 3 is appropriate given 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 '查询某个类或接口的完整属性和方法' (query the complete properties and methods of a class or interface), providing a specific verb and resource. It distinguishes this tool from siblings like get_method (specific method) and get_module (module-level).

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 does not explicitly state when to use this tool vs alternatives, but the purpose is clear enough that usage is implied — if you need full class/interface details, this is the tool. No exclusions or alternative recommendations are provided, so guidance is inferred rather than explicit.

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

get_methodB

查询某个类的特定方法签名和说明

ParametersJSON Schema

Name	Required	Description	Default
`className`	Yes	类名
`methodName`	Yes	方法名

TDQS

B3.2/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 of behavioral disclosure. It implies a read-only operation via '查询' (query) and states that the result includes the method signature and description. However, it does not disclose error handling, permission requirements, or the exact structure of the returned signature. For a simple getter, this is moderate but not detailed.

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, focused sentence that front-loads the action and resource. It contains no filler, repetition, or extraneous details. Every word contributes to the core purpose, making it a model of conciseness.

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?

There is no output schema, so the description should explain what the tool returns. While it mentions '签名和说明' (signature and description), it does not specify the structure of the signature (e.g., parameters, return type) or any edge-case behavior. Given the tool's simplicity, the lack of output format details leaves an important gap for an agent deciding whether the result will be sufficient.

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 descriptions cover both parameters fully (className and methodName), with 100% coverage. The description does not add any additional meaning beyond the schema; it simply references the class and method context. Given the high schema coverage, a baseline score of 3 is appropriate.

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: '查询某个类的特定方法签名和说明' (query the signature and description of a specific method of a class). It uses a specific verb ('查询') and resource ('特定方法的签名和说明') that distinguishes it from sibling tools like get_class and get_module. However, it does not explicitly contrast itself with these alternatives, so it stops short of a 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. It does not mention that get_method is for method-level details, or suggest using get_class for class-level details, or search_api for finding methods. There is no 'use this when' or 'use that when' information, so the agent has no support for choosing between siblings.

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

get_moduleA

查询某个模块包含的所有类和接口

ParametersJSON Schema

Name	Required	Description	Default
`moduleName`	Yes	模块名，如 exia-ccui、exia-data、exia-event、cocos

TDQS

A3.6/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 full responsibility for behavioral disclosure. The description only states the query action but does not explicitly confirm read-only behavior, mention any side effects, permissions, or note the return format beyond the fact that it returns classes and interfaces. For a tool with no annotations, 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 a single clear sentence with no fluff, redundant information, or unnecessary detail. It effectively communicates the core purpose without waste.

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?

Given the tool's low complexity (one parameter, simple purpose) and the well-described schema, the description is mostly complete. It states the output (all classes and interfaces), which partially compensates for the lack of an output schema. However, the absence of behavioral transparency and usage alternatives prevents a perfect score.

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 single parameter 'moduleName' is fully described in the schema with examples (exia-ccui, exia-data, etc.), so schema coverage is 100%. The tool description adds no additional parameter semantics beyond what the schema already provides. The baseline of 3 applies because the schema does the heavy lifting.

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 function: query all classes and interfaces in a module. It uses a specific verb ('查询') and resource ('模块'), and the result set is explicit. This distinguishes it from sibling tools like get_class and get_method, which target individual elements, and search_api, which searches differently.

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 (use when you need all classes/interfaces of a module) but does not explicitly mention alternatives or when not to use this tool. No guidance is given on how to choose between get_module and search_api, get_class, or get_method. This is an implied, not explicit, usage context.

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

search_apiB

按关键词搜索框架或Cocos API，支持中英文

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	搜索关键词，如"延迟执行"、"窗口显示"、"资源加载"
`source`	No	搜索范围	all

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full behavioral disclosure burden. It only mentions keyword search and bilingual support, but fails to disclose read-only nature, result format, pagination, or other behavioral traits. 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 a single, concise sentence that immediately conveys the tool's purpose with no unnecessary detail. It is front-loaded with the main verb and resource.

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 simple, and the description covers its core purpose. However, it lacks any mention of return values or usage context, and no output schema exists to compensate. It is minimally sufficient but not comprehensive.

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 already provides full descriptions for both parameters: query includes examples like '延迟执行' and source includes an enum with meaning. With 100% schema description coverage, the description does not need to add parameter details, so baseline 3 applies.

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 '按关键词搜索框架或Cocos API' (search by keyword for framework or Cocos API), specifying a concrete verb and resource. This distinguishes it from sibling tools like get_module, get_class, and get_method, which are targeted retrievals rather than broad searches.

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 instead of siblings. It 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.

Tool Schema Changelog

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

4 tool updatesv1.0.0Aug 10, 2026
- First observedget_class
- First observedget_method
- First observedget_module
- First observedsearch_api

Install Server

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

TDQS

A3.7/5.0

Scored 2026-08-10 05:45 across 4 tools

Disambiguation5/5

Each tool targets a distinct level of the API knowledge hierarchy: search, module, class, and method. There is no overlap in purpose; search returns results, while the get_* tools retrieve specific entities. The hierarchy is clear and unambiguous.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: search_api, get_module, get_class, get_method. This makes the pattern predictable and easy to infer for additional tools.

Tool Count4/5

Four tools is a minimal but well-scoped set for an API knowledge server. Each tool covers a distinct retrieval need, and the count is neither excessive nor trivially small for the stated purpose.

Completeness4/5

The set covers the core workflow of searching, navigating to a module, inspecting a class, and getting method details. A minor gap is the absence of a direct 'list modules' tool, but search provides an entry point, making the surface reasonably complete.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

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

docs A
com.ntop
Search and query nTop's knowledge base and engineering guides from AI applications.
Search Documentation Access
32
@imqueue A
org.imqueue
Search @imqueue docs and scaffold typed services & clients from your AI coding agent.
Developer Tools Documentation Access
711
llmref A
org.llmref
Versioned documentation registry and semantic search for AI tools and coding assistants.
Documentation Access Search Developer Tools
42
Recall A
io.github.mcp-dir
Recall (recall.it) — your AI knowledge base / 'second brain'. Via the official API: semantic search
Knowledge & Memory RAG Systems Search
101

Related MCP Servers

cocos_mcp
Games & Gamification Developer Tools AI & Machine Learning
hzq510473048
A
license
Not graded
quality
D
maintenance
Enables AI assistants to control Cocos Creator game development directly within the engine, providing tools for node manipulation, asset management, scene operations, and AI-powered image generation.
Updated 4 months ago (2026-05-14 12:53 UTC)
19
ISC
cocos-mcp-server
Developer Tools Games & Gamification
caravanglory
A
license
Not graded
quality
F
maintenance
Enables AI assistants to directly control the Cocos Creator 3.8.x editor via MCP protocol, providing over 130 tools for scene, node, component, asset, and project operations.
Updated 6 months ago (2026-02-26 15:26 UTC)
24
39
MIT
Cocos Creator MCP Server
557888-pixel
-
license
Not graded
quality
Not graded
maintenance
Enables AI assistants to interact with the Cocos Creator 3.8+ editor through standardized protocols for scene, node, component, prefab, asset, project, debugging, and server operations.
Updated 3 months ago (2026-06-06 00:19 UTC)
-
Cocos Creator MCP Server
Developer Tools
vuquangdang2002
A
license
Not graded
quality
D
maintenance
A comprehensive MCP server for Cocos Creator 3.8+ that enables AI assistants to interact with the editor via 50+ tools for scene, node, component, prefab, asset, and project management.
Updated 3 months ago (2026-06-18 01:47 UTC)
24
MIT

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/xiachenggang/exia-framework-mcp'

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