Skip to main content
Glama
tony2026m

@tony2026m/mybatis-flex-mcp

by tony2026m
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

@tony2026m/mybatis-flex-mcp

npm version license Node.js version

An MCP (Model Context Protocol) service for Mybatis-Flex API query | 一个减少 Mybatis-Flex 框架实现数据库操作代码时产生幻觉的 MCP 服务

📖 简介

@tony2026m/mybatis-flex-mcp 是一个专为 MyBatis-Flex ORM 框架设计的 MCP 服务器，提供：

  • 🔍 API 列表查询 - 快速浏览 MyBatis-Flex 所有可用的功能和 API

  • 📚 功能文档查询 - 获取详细的功能使用文档、API 说明和使用场景

  • 💡 代码示例获取 - 提供实际可运行的代码示例

  • 📝 更新日志查询 - 了解 MyBatis-Flex 的版本变更历史

  • 🎯 系统提示词 - 内置专业的 MyBatis-Flex 使用指导

  • ⚡ 缓存机制 - 提供高性能的文档查询体验

Related MCP server: mcp-server-apidebug

什么时候需要自行提取文档？

  1. 你想使用最新版本的 MyBatis-Flex 文档

  2. 你想使用特定版本的 MyBatis-Flex 文档

提取 MyBatis-Flex 文档

# 克隆 MyBatis-Flex 仓库
git clone https://github.com/mybatis-flex/mybatis-flex.git ./.temp/mybatis-flex --depth 1 --branch master --single-branch --filter=blob:none

# 在当前目录执行提取文档命令
npx @tony2026m/mybatis-flex-mcp extract [mybatis-flex repo path]  # 默认提取路径为 ./.temp/mybatis-flex

🚀 快速开始

作为 MCP 服务器使用（推荐）

在 Cursor 或其他支持 MCP 的 AI 编辑器中配置：

{
  "mcpServers": {
    "Mybatis-Flex": {
      "command": "npx",
      "args": ["@tony2026m/mybatis-flex-mcp"]
    }
  }
}

或者使用本地安装：

npm install -g @tony2026m/mybatis-flex-mcp

然后配置：

{
  "mcpServers": {
    "Mybatis-Flex": {
      "command": "mybatis-flex-mcp"
    }
  }
}

直接运行

# 使用 npx（无需安装）
npx @tony2026m/mybatis-flex-mcp

# 或全局安装后运行
npm install -g @tony2026m/mybatis-flex-mcp
mybatis-flex-mcp

🛠️ 可用工具

MCP 服务器提供以下工具：

1. list-api

列出所有可用的 MyBatis-Flex 功能和 API

使用场景：

  • 当用户进行后端开发，需要使用 MyBatis-Flex 进行数据库操作时

  • 查看框架提供的所有功能模块和 API

2. get-api-doc

获取特定功能或 API 的详细文档

参数：

  • apiName - API 或功能名称（如 "QueryWrapper"、"IService"、"@Table 注解" 等）

使用场景：

  • 用户询问如何使用特定 API 或功能

  • 需要查看 API 的介绍、使用限制、使用场景、示例代码等

3. get-changelog

获取 MyBatis-Flex 的更新日志

使用场景：

  • 了解 MyBatis-Flex 的版本变更历史

  • 查看特定版本的新增功能和修复

4. get-mybatis-flex-info

获取 MyBatis-Flex 的概况信息和当前版本

使用场景：

  • 了解 MyBatis-Flex 框架的基本信息

  • 查看当前文档对应的版本

📚 支持的功能模块

本 MCP 服务涵盖 MyBatis-Flex 的所有核心功能：

  • 简介模块: 快速开始、Maven 依赖、数据库支持等

  • 基础功能: 增删改查、QueryWrapper、链式操作、关联查询、批量操作等

  • 核心功能: 注解配置、逻辑删除、乐观锁、数据填充、多数据源、读写分离、数据权限、多租户等

  • 其他功能: 代码生成器、APT 设置、常见问题等

📦 系统要求

  • Node.js >= 20.0.0

  • 支持 MCP 协议的客户端（如 Cursor、Claude Desktop 等）

🔧 开发

# 克隆仓库
git clone https://github.com/tony2026m/mybatis-flex-mcp.git
cd mybatis-flex-mcp

# 安装依赖
pnpm install

# 开发模式
pnpm dev

# 构建
pnpm build

# 测试
pnpm test

# 使用 MCP Inspector 调试
pnpm inspector

📄 许可证

MIT License - 详见 LICENSE 文件

🤝 贡献

欢迎提交 Issue 和 Pull Request！

👨‍💻 作者

tony2026m

🙏 致谢

本项目基于 MyBatis-Flex 官方文档构建。

📝 更新日志

查看 CHANGELOG.md 了解版本历史。

Available Tools

4 tools
get-api-docA

通过名称，获取 Mybatis-Flex（mybatis-flex） 特定功能api的详细文档 适用场景：

  1. 用户询问如何使用特定api或功能

  2. 用户需要查看api、功能的 介绍，使用限制、使用场景、示例代码等

ParametersJSON Schema
NameRequiredDescriptionDefault
apiNameYesapi或功能名称。例如：IService, QueryWrapper, @Table 注解等

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of disclosing behavior. It communicates that the tool returns detailed documentation including introduction, limitations, scenarios, and example code, making the read-only nature and expected output clear. Minor gaps around not-found or error behavior remain.

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 concise and front-loaded: one clear purpose sentence followed by a short bulleted list of scenarios. Every sentence earns its place and there is no redundant or vague phrasing.

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 tool with one required parameter and no output schema, the description covers both tool selection and expected return content. It could be more complete by hinting that list-api can be used first if the exact API name is unknown, and by explaining failure behavior, but these are minor omissions.

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 describes the single parameter apiName with concrete examples like IService, QueryWrapper, and @Table. The description only adds 'by name', which does not meaningfully extend the schema's parameter documentation. Given 100% schema coverage, the baseline of 3 is appropriate.

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 a specific action and resource: fetch detailed documentation for a named Mybatis-Flex API/feature via its name. It is distinguishable from siblings like list-api, get-changelog, and get-mybatis-flex-info, which serve different purposes.

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 applicable scenarios are explicitly listed: when the user asks how to use a specific API/function, or needs its introduction, usage restrictions, scenarios, and examples. It does not explicitly mention alternatives or when-not-to-use cases, so it misses the top score.

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

get-changelogA

获取 Mybatis-Flex（mybatis-flex）的更新日志 Changelog 适用场景：

  1. 需要了解框架的更新历史时

  2. 需要知道框架更新、新增了哪些特性、功能时

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the burden and clearly states the tool is a read-only retrieval of the changelog ('获取'). It does not mention output format or source, but for a zero-parameter read tool there is little additional behavioral risk to disclose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with numbered use cases, front-loaded with the verb and resource. The two use cases somewhat overlap, which prevents a 5.

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 parameterless read-only changelog tool with no annotations and no output schema, the description tells the agent what the tool returns and when to use it. Nothing necessary for correct invocation is missing.

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?

There are zero parameters, so the baseline is 4; the description correctly focuses on purpose rather than parameter details.

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?

Description states "获取 Mybatis-Flex（mybatis-flex）的更新日志 Changelog" — a specific verb and resource. It is clearly distinct from siblings list-api, get-api-doc, and get-mybaitis-flex-info because it targets the project changelog rather than API listings or general framework info.

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?

Provides explicit use cases: wanting to review framework update history or learn about newly added features. It does not explicitly exclude any sibling, but the scenarios are specific enough that no agent would confuse it with the sibling tools.

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

get-mybatis-flex-infoA

获取 Mybatis-Flex（mybatis-flex）简介、概况信息、version 适用场景：

  1. 用户询问什么是 Mybatis-Flex（mybatis-flex）

  2. 用户需要知道 Mybatis-Flex（mybatis-flex）的版本信息时

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.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 must carry the behavioral burden. It conveys that the tool is a read-only information retrieval (via '获取'), but it does not disclose any additional traits such as whether the version data is live, cached, or how errors surface. The absence is not severe for a zero-parameter getter, but the description stays at a core-outcome level.

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 compact and front-loaded with the action, then enriched by a clear two-item usage-scenario list. Every line carries purpose and there is no redundant filler.

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 zero-parameter, no-output-schema tool, the description provides enough context: the target framework, the information type, and when to apply it. It could go further by explicitly distinguishing itself from get-changelog/get-api-doc, but that is already implicit in the stated resource.

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 input schema is empty and schema coverage is 100%, so the baseline for zero parameters is 4. The description adds no parameter details because there are none to explain; its content about returning intro/overview/version is the only context needed.

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 states a specific verb ('获取') and resource (Mybatis-Flex) and indicates the information covered (简介、概况信息、version). This clearly separates it from sibling tools like list-api or get-changelog, which focus on different resources.

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 explicitly lists two applicable scenarios: when the user asks what Mybatis-Flex is and when they need version info. However, it does not mention when not to use the tool or name any sibling alternatives, so it stops short of full routing guidance.

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

list-apiA

当用户根据业务需求和PRD进行后端开发，需要使用 Mybatis-Flex（mybatis-flex）框架进行数据库操作时使用此工具。 此工具仅返回框架可用的功能(API)列表。 调用此工具后，你必须根据你的业务需求、来选择符合你业务需求的功能api，进行数据库的构建和数据操作

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden. It explicitly says the tool 'only returns a list' and clarifies that actual database construction and operations happen afterward by the agent, which communicates that this tool is read-only and non-mutating.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is reasonably concise and front-loads the usage condition, then states the behavior and expected follow-up. There is slight redundancy in repeating '根据你的业务需求', but overall it is direct and efficient.

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?

This is a zero-parameter listing tool with no output schema and no annotations. The description covers when to use it, what it returns, and what the agent should do after calling it, which is enough for an agent to start correctly. It does not describe the list's format, but for a simple list-API tool that is a minor gap.

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 no parameters, so the description does not need to explain parameter details. The baseline of 4 applies, and nothing in the description contradicts the empty schema.

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 that the tool returns a list of framework-available APIs for Mybatis-Flex database operations. It identifies a specific verb and resource, but does not explicitly differentiate itself from sibling tools like get-api-doc or get-mybatis-flex-info.

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 gives a clear context for use: when the user is doing backend development with Mybatis-Flex and needs to perform database operations. It does not mention alternatives or exclusion conditions, so it stops short of a 5.

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. 4 tool updatesv0.2.0
    • First observedget-api-doc
    • First observedget-changelog
    • First observedget-mybatis-flex-info
    • First observedlist-api
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

A4.4/5.0

Scored across 4 tools

Disambiguation5/5

Each tool serves a distinct function: listing available APIs, fetching a specific API's docs, retrieving the changelog, and getting framework overview/version info. There is no meaningful overlap in purpose or output, so an agent can reliably choose the correct tool.

Naming Consistency5/5

All tool names follow a consistent lowercase verb-noun hyphenated pattern: list-api, get-api-doc, get-changelog, and get-mybatis-flex-info. The verb prefix clearly indicates the operation, and the noun identifies the target resource.

Tool Count5/5

Four tools are well-suited for a focused documentation and API-lookup MCP server. Each tool earns its place without redundancy or excessive granularity.

Completeness5/5

The tool set covers API enumeration, detailed API documentation, changelog history, and framework overview/version information. These are the core needs for developers using Mybatis-Flex, and no significant gaps or dead ends are apparent.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers