Built on Python, offering a modular architecture that enables developers to easily extend AI application functionality through a standardized module interface.
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-BOS list all available modules"
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.
使用基于约定的自动模块发现机制，为Claude Desktop打造的灵活MCP服务器框架。通过简洁的模块接口和声明式配置，轻松扩展AI应用功能，无需修改核心代码。支持FastMCP标准，包含完整工具、资源和提示模板注册能力。
🧩 模块化设计：功能以自包含模块组织，便于扩展
🔍 自动发现：约定优于配置的模块加载方式
⚙️ 声明式配置：通过config.json灵活配置模块和参数
🔌 即插即用：新功能只需添加符合接口的模块目录
🔒 安全稳定：分层架构确保核心系统稳定可靠
📝 详细日志：完善的日志系统便于调试与监控
🖥️ Claude Desktop集成：与Claude深度集成，提供AI增强体验
Related MCP server: Filesystem MCP Server
Python FastMCP Model Context Protocol Claude Desktop JSON 模块化设计 微内核架构
MCP-BOS框架采用了现代化的模块化架构设计，主要设计理念包括：
整个框架以模块为中心，每个功能都被封装在独立的模块中，使功能扩展变得简单直观。模块之间相互独立，但又通过标准接口相互协作，形成一个完整的服务生态。
框架能够自动发现modules目录下的模块，无需手动注册每个模块。这种"约定优于配置"的方式大幅降低了扩展成本。
通过config.json文件进行全局和模块级别的配置，使框架具有很高的灵活性，可以根据不同需求启用或禁用特定模块。
框架分为核心层和模块层，核心层负责框架基础功能，模块层负责具体业务功能，这种分层设计使框架更加健壮和可维护。
mcp-bos/
├── config.json # 全局配置文件
├── main.py # 主入口文件
├── core/ # 核心系统
│ ├── __init__.py
│ ├── module_registry.py # 模块注册表
│ ├── module_loader.py # 模块加载器
│ ├── module_interface.py # 模块接口定义
│ ├── config_manager.py # 配置管理器
│ └── server.py # FastMCP服务器适配
├── modules/ # 功能模块目录
│ ├── __init__.py
│ ├── hello_world/ # Hello World示例模块
│ │ ├── __init__.py
│ │ └── hello.py
│ └── ... # 其他功能模块
├── utils/ # 工具函数
│ ├── __init__.py
│ └── helpers.py
└── README.md # 项目文档main.py: 框架入口点，负责初始化和启动服务器
core/: 核心组件目录
module_interface.py: 定义所有模块必须实现的接口
module_registry.py: 管理已注册的模块
module_loader.py: 自动发现和加载模块
config_manager.py: 加载和管理配置
server.py: 与FastMCP集成，提供服务器功能
modules/: 功能模块目录，每个子目录是一个独立模块
utils/: 通用工具函数
config.json文件是框架的核心配置，分为全局配置和模块配置两部分：
{
"global": {
"server_name": "MCP-BOS",
"debug": true,
"log_level": "INFO",
"transport": "stdio",
"dependencies": ["mcp[cli]"]
},
"modules": {
"hello_world": {
"enabled": true,
"message": "Hello, {}!"
},
"module_name": {
"enabled": false,
"param1": "value1"
}
}
}global: 全局配置部分
server_name: 服务器名称
debug: 是否启用调试模式
log_level: 日志级别
transport: 传输协议，通常为"stdio"
dependencies: 依赖包列表
modules: 模块配置部分，每个模块有自己的配置节
enabled: 是否启用该模块
其他模块特定的配置参数
克隆仓库:
git clone https://github.com/kinbos/mcp-bos.git
cd mcp-bos安装依赖:
uv pip install mcp[cli]编辑config.json文件来配置服务器和模块：
设置服务器名称、日志级别等全局参数
启用或禁用模块
配置模块特定参数
有以下几种方式运行服务器:
直接运行:
python main.py使用uv运行:
uv run main.py与Claude Desktop集成:
# 使用mcp CLI集成到Claude Desktop
mcp install main.py开发调试模式:
# 使用mcp Inspector测试服务器
mcp inspect main.py在modules目录下创建一个新的模块目录:
mkdir modules/my_module创建必要的文件:
touch modules/my_module/__init__.py
touch modules/my_module/my_module.py实现模块接口:
# modules/my_module/my_module.py
from core.module_interface import ModuleInterface
class MyModule(ModuleInterface):
def get_info(self):
return {
"name": "my_module",
"version": "1.0.0",
"description": "我的自定义模块",
"author": "kinbos 严富坤",
"email": "fookinbos@gmail.com",
"website": "htttps://www.yanfukun.com"
}
def register(self, server):
@server.tool()
def my_tool(param: str) -> str:
"""自定义工具"""
return f"处理参数: {param}"
@server.resource("my://resource")
def my_resource() -> str:
"""自定义资源"""
return "资源内容"导出模块类:
# modules/my_module/__init__.py
from modules.my_module.my_module import MyModule
__all__ = ['MyModule']在配置文件中启用模块:
{
"modules": {
"my_module": {
"enabled": true,
"custom_param": "value"
}
}
}重启服务器，新模块将被自动发现和加载
检查模块目录结构是否正确
确认__init__.py文件是否导出了模块类
检查配置文件中模块是否启用
查看日志输出，了解详细错误信息
如果在Windows环境下遇到中文编码问题，确保设置了正确的环境变量:
"env": {
"PYTHONIOENCODING": "utf-8"
}确认Claude Desktop已正确配置
检查依赖是否正确安装
查看Claude Desktop日志文件
欢迎提交贡献，请遵循以下步骤:
Fork项目
创建功能分支
提交更改
创建Pull Request
kinbos 严富坤 - 个人网站
两个整数的和相加
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes |
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 the mathematical operation without mentioning any behavioral traits like error handling, performance characteristics, or side effects. For a simple tool, this might be acceptable, but it lacks completeness for an agent to fully understand its behavior.
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 extremely concise with a single phrase ('两个整数的和相加'), which is front-loaded and wastes no words. For a simple addition tool, this brevity is appropriate and efficient, making it easy for an agent to parse quickly.
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 (2 parameters, no annotations, no output schema), the description is minimal. It states the basic purpose but lacks details on usage, parameters, or behavioral context. While the tool is straightforward, the description doesn't provide enough information for an agent to confidently select and invoke it without additional inference.
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 schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. The description mentions '两个整数' (two integers), which aligns with the two parameters 'a' and 'b', but it doesn't add any semantic meaning beyond what's implied by the parameter names. It doesn't explain what 'a' and 'b' represent or any constraints beyond being integers.
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 '两个整数的和相加' (sum of two integers) states what the tool does with a specific verb ('相加' - add/sum) and resource ('整数' - integers), but it's somewhat vague about the exact operation. It doesn't distinguish from siblings like 'hello' or 'server_info', but those are clearly different tools, so differentiation isn't critical 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, context for use, or comparisons to other tools. The agent must infer usage solely from the tool name and description without explicit guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
返回问候消息
Args: name: 要问候的名称
Returns: str: 问候消息
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | World |
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 the tool returns a greeting message as a string, but doesn't describe any behavioral traits such as side effects, error handling, or performance characteristics. For a simple tool, this might be minimal, but it lacks details like whether it's idempotent or has any constraints.
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 concise and structured with clear sections for Args and Returns, using minimal text. It avoids unnecessary details, making it easy to scan. However, it could be more front-loaded by stating the purpose more prominently before the parameter details.
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 low complexity (one optional parameter, no output schema, no annotations), the description is somewhat complete but has gaps. It explains the basic input and output, but lacks usage context and behavioral details. For a simple greeting tool, this might be adequate, but it doesn't fully cover all aspects needed for optimal agent invocation.
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 adds that the parameter 'name' is '要问候的名称' (the name to greet), which provides basic semantic meaning. However, with 0% schema description coverage and only one parameter documented in the description, it partially compensates but doesn't fully explain the default value 'World' or any validation rules. The baseline is 3 since the schema covers the parameter structure, but the description adds limited value.
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 states the tool '返回问候消息' (returns a greeting message), which clearly indicates its purpose. However, it doesn't specify the exact format or content of the greeting beyond returning a string, and it doesn't differentiate from sibling tools like 'add' or 'my_tool' which have unrelated functions. The purpose is understandable but somewhat vague in execution details.
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 context, prerequisites, or exclusions for usage. Given that sibling tools include 'add' (likely for arithmetic) and 'my_tool' (unspecified), there's no indication of when a greeting tool is appropriate versus other operations.
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 |
|---|---|---|---|
| param | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but fails completely. '自定义工具' gives no indication of whether this is a read/write operation, its side effects, permissions needed, or any behavioral traits.
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?
While technically concise with just three characters, this is under-specification rather than effective brevity. The description fails to convey necessary information, making it inefficient despite its short length.
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?
For a tool with one undocumented parameter, no annotations, and no output schema, the description is completely inadequate. It provides no functional context, parameter guidance, or behavioral information needed for proper tool invocation.
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?
Schema description coverage is 0%, and the description provides no information about the single required parameter 'param'. It doesn't explain what 'param' represents, its format, or how it influences the tool's behavior.
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 '自定义工具' (custom tool) is a tautology that merely restates the tool name 'my_tool' without specifying what it actually does. It provides no verb, resource, or functional purpose, and doesn't distinguish it from sibling tools like 'add', 'hello', or 'server_info'.
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 offers no guidance on when to use this tool versus alternatives. There's no mention of context, prerequisites, or comparisons with sibling tools, leaving the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取服务器信息
Args: ctx: MCP上下文
Returns: dict: 服务器信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states that it returns server information as a dict, without disclosing behavioral traits like whether it's read-only, has side effects, requires authentication, or has rate limits. For a tool with zero annotation coverage, this is insufficient transparency.
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 brief but includes unnecessary structural elements like 'Args:' and 'Returns:' that don't add value beyond the schema. The core purpose is stated in one line, but the formatting could be more streamlined. It's not excessively verbose but has minor structural inefficiencies.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what 'server information' includes, the format of the dict return value, or any behavioral context. For a tool that presumably provides system-level data, more detail is needed to be fully useful to an AI agent.
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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description adds no parameter information beyond what the schema provides, but with no parameters, a baseline of 4 is appropriate as there's nothing to compensate for.
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 states '获取服务器信息' (get server information), which provides a basic verb+resource purpose. However, it's vague about what specific server information is retrieved and doesn't differentiate from sibling tools like 'hello' or 'my_tool'. The purpose is clear but lacks specificity and sibling differentiation.
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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention any context, prerequisites, or exclusions for usage. With sibling tools like 'add', 'hello', and 'my_tool' available, there's no indication of when this specific tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The tools are highly ambiguous and overlapping in purpose. 'add' performs arithmetic, 'hello' returns a greeting, 'my_tool' is described only as 'custom tool' with no clear purpose, and 'server_info' retrieves server metadata. 'my_tool' is completely undefined, making it impossible to distinguish from others, and the set lacks clear domain boundaries, leading to high misselection risk.
Naming is inconsistent with mixed conventions. 'add' and 'hello' use simple verb forms, 'my_tool' uses a vague noun phrase, and 'server_info' uses a noun_verb pattern. There is no predictable naming scheme across the set, though all names are readable in English.
With only 4 tools, the count feels too thin for any coherent domain. The tools span arithmetic, greetings, an undefined custom function, and server metadata, suggesting a poorly scoped utility set rather than a focused server purpose. This minimal count does not adequately cover a meaningful operational surface.
The tool set is severely incomplete for any inferable domain. If interpreted as a general utility server, it lacks basic operations like subtraction, multiplication, or data processing. The inclusion of 'my_tool' without description creates a dead end, and there are significant gaps that will cause agent failures due to missing core functionalities.
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…
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
A Model Context Protocol server for Wix AI tools
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/gooboot/MCP-BOS'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
