Get笔记 MCP Server
This MCP server integrates Get笔记 (GetBiji) knowledge bases with Claude Desktop, enabling AI-powered search and retrieval of stored information.
Core Tools:
AI-Enhanced Search (
knowledge_search): Perform deep, AI-processed searches that synthesize comprehensive answers from your knowledge base, with support for deep thinking mode, reference inclusion, and conversation history for follow-up questionsRaw Content Recall (
knowledge_recall): Quickly retrieve unprocessed original content without AI processing, with options for intent rewriting, result re-selection, top K filtering, and conversation contextRate Limit Monitoring (
get_rate_limit_stats): Check current API usage statistics for QPS (2 requests/second) and daily quota (5000 requests/day)
Key Features:
Automatic rate limit management with intelligent queuing
Flexible configuration via environment variables (API key, base URL, default knowledge base, timeout, logging level)
Multiple installation options (global, npx, local dependency)
Bearer token authentication for secure API access
Type-safe TypeScript implementation with comprehensive error handling and logging
Seamless Claude Desktop integration
Click on "Deploy 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., "@Get笔记 MCP Serversearch for information about TypeScript best practices"
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.
Get笔记 MCP Server
<a name="english"></a>
English
Overview
A Model Context Protocol (MCP) server for integrating with Get笔记 (GetBiji) API, enabling AI-powered knowledge base search and retrieval capabilities.
Features
✅ MCP server framework with stdio transport
✅ Get笔记 API client with Bearer token authentication
✅ Rate limiting (2 QPS, 5000 requests/day)
✅ Comprehensive error handling and logging
✅ TypeScript with full type safety
✅ Three MCP tools:
knowledge_search: AI-enhanced knowledge base searchknowledge_recall: Raw content retrievalget_rate_limit_stats: Rate limit statistics
Installation
Option 1: Install globally (recommended for frequent use)
npm install -g mcp-get-biji-serverOption 2: Use with npx (no installation required)
npx mcp-get-biji-serverOption 3: Install as project dependency
npm install mcp-get-biji-serverConfiguration
Copy the environment template:
cp .env.example .envEdit
.envand add your API key:
GET_BIJI_API_KEY=your_api_key_here
GET_BIJI_API_BASE_URL=https://open-api.biji.com/getnote/openapi
LOG_LEVEL=info
REQUEST_TIMEOUT=30000
RATE_LIMIT_QPS=2
RATE_LIMIT_DAILY=5000Usage with Claude Desktop
Edit your Claude Desktop config file (~/Library/Application Support/Claude/claude_desktop_config.json):
Using global installation:
{
"mcpServers": {
"get-biji": {
"command": "mcp-get-biji-server",
"env": {
"GET_BIJI_API_KEY": "your_api_key_here",
"GET_BIJI_DEFAULT_TOPIC_ID": "your_default_topic_id"
}
}
}
}Using npx:
{
"mcpServers": {
"get-biji": {
"command": "npx",
"args": ["-y", "mcp-get-biji-server"],
"env": {
"GET_BIJI_API_KEY": "your_api_key_here",
"GET_BIJI_DEFAULT_TOPIC_ID": "your_default_topic_id"
}
}
}
}Using local installation:
{
"mcpServers": {
"get-biji": {
"command": "node",
"args": ["/path/to/node_modules/mcp-get-biji-server/build/index.js"],
"env": {
"GET_BIJI_API_KEY": "your_api_key_here",
"GET_BIJI_DEFAULT_TOPIC_ID": "your_default_topic_id"
}
}
}
}Restart Claude Desktop to activate the server.
MCP Tools
1. knowledge_search
AI-enhanced search with deep processing, providing comprehensive answers based on your knowledge base.
Parameters:
question(required): Search querytopic_ids(optional): Knowledge base ID list (currently supports 1) - can be omitted if configured via GET_BIJI_DEFAULT_TOPIC_IDdeep_seek(required): Enable deep thinkingrefs(optional): Include referenceshistory(optional): Conversation history for follow-up
2. knowledge_recall
Fast retrieval of raw content without AI processing, useful for quick previews and raw data access.
Parameters:
question(required): Search querytopic_id(optional): Single knowledge base ID (preferred)topic_ids(optional): Knowledge base ID listtop_k(optional): Number of top results (default: 10)intent_rewrite(optional): Enable intent rewritingselect_matrix(optional): Enable result re-selectionhistory(optional): Conversation history
Note: Either topic_id or topic_ids can be omitted if configured via GET_BIJI_DEFAULT_TOPIC_ID. topic_id takes priority if both are provided.
3. get_rate_limit_stats
Get current API rate limit usage statistics.
Development
npm run build # Compile TypeScript
npm run watch # Watch mode compilation
npm run dev # Build and run
npm test # Run tests
npm start # Run (must build first)API Rate Limits
QPS: 2 requests/second
Daily: 5000 requests/day
The server automatically handles rate limiting with intelligent queuing.
Project Structure
.
├── src/ # Source code
│ ├── index.ts # MCP server entry
│ ├── client.ts # API client
│ ├── config.ts # Configuration
│ ├── logger.ts # Logging system
│ ├── rate-limiter.ts # Rate limiter
│ ├── types.ts # Type definitions
│ └── test.ts # Test script
├── build/ # Compiled output
├── .env # Environment variables
└── package.json # Project configTech Stack
Node.js (ES Modules)
TypeScript
@modelcontextprotocol/sdk
Axios
dotenv
License
MIT
Related MCP server: Get Notes MCP Server
Contributing
Contributions welcome! Please open an issue or submit a pull request.
Special thanks to the contribution & development of Xiaoyibao-Pancrepal & xiao-x-bao community to support cancer/rare disease patients and their families with ❤️ & AI!
This project is proudly supported by the xiao-x-bao community, dedicated to helping cancer and rare disease patients and their families through AI technology and community support.
<a name="chinese"></a>
中文
项目概述
一个用于集成Get笔记API的Model Context Protocol (MCP)服务器,实现AI增强的知识库搜索和召回功能。
功能特性
✅ 基于stdio传输的MCP服务器框架
✅ 支持Bearer Token认证的Get笔记API客户端
✅ 速率限制 (2 QPS, 5000次/天)
✅ 完善的错误处理和日志记录
✅ TypeScript完整类型安全
✅ 三个MCP工具:
knowledge_search: AI增强知识库搜索knowledge_recall: 原始内容召回get_rate_limit_stats: 速率限制统计
安装
方式1: 全局安装 (推荐常用场景)
npm install -g mcp-get-biji-server方式2: 使用 npx (无需安装)
npx mcp-get-biji-server方式3: 作为项目依赖安装
npm install mcp-get-biji-server配置
复制环境变量模板:
cp .env.example .env编辑
.env文件,添加您的API密钥:
GET_BIJI_API_KEY=your_api_key_here
GET_BIJI_API_BASE_URL=https://open-api.biji.com/getnote/openapi
LOG_LEVEL=info
REQUEST_TIMEOUT=30000
RATE_LIMIT_QPS=2
RATE_LIMIT_DAILY=5000在Claude Desktop中使用
编辑Claude Desktop配置文件 (~/Library/Application Support/Claude/claude_desktop_config.json):
使用全局安装:
{
"mcpServers": {
"get-biji": {
"command": "mcp-get-biji-server",
"env": {
"GET_BIJI_API_KEY": "your_api_key_here",
"GET_BIJI_DEFAULT_TOPIC_ID": "your_default_topic_id"
}
}
}
}使用 npx:
{
"mcpServers": {
"get-biji": {
"command": "npx",
"args": ["-y", "mcp-get-biji-server"],
"env": {
"GET_BIJI_API_KEY": "your_api_key_here",
"GET_BIJI_DEFAULT_TOPIC_ID": "your_default_topic_id"
}
}
}
}使用本地安装:
{
"mcpServers": {
"get-biji": {
"command": "node",
"args": ["/path/to/node_modules/mcp-get-biji-server/build/index.js"],
"env": {
"GET_BIJI_API_KEY": "your_api_key_here",
"GET_BIJI_DEFAULT_TOPIC_ID": "your_default_topic_id"
}
}
}
}重启Claude Desktop以激活服务器。
MCP工具说明
1. knowledge_search
AI增强搜索,返回经过深度处理的答案。
参数:
question(必填): 搜索问题topic_ids(必填): 知识库ID列表(当前只支持1个)deep_seek(必填): 启用深度思考refs(可选): 返回引用来源history(可选): 对话历史,用于追问
2. knowledge_recall
快速召回原始内容,不经过AI处理。
参数:
question(必填): 搜索问题topic_id(可选): 单个知识库ID(优先使用)topic_ids(可选): 知识库ID列表top_k(可选): 返回前N个结果(默认:10)intent_rewrite(可选): 启用意图重写select_matrix(可选): 启用结果重选history(可选): 对话历史
注意: topic_id 和 topic_ids 必须提供一个,优先使用 topic_id。
3. get_rate_limit_stats
获取当前API速率限制使用统计。
开发命令
npm run build # 编译TypeScript代码
npm run watch # 监听模式编译
npm run dev # 编译并运行
npm test # 运行测试
npm start # 直接运行(需先编译)API限制
QPS限制: 2次/秒
日限制: 5000次/天
服务器内置智能排队的速率限制器,自动处理这些限制。
项目结构
.
├── src/ # 源代码目录
│ ├── index.ts # MCP服务器入口
│ ├── client.ts # API客户端
│ ├── config.ts # 配置管理
│ ├── logger.ts # 日志系统
│ ├── rate-limiter.ts # 速率限制器
│ ├── types.ts # TypeScript类型定义
│ └── test.ts # 测试脚本
├── build/ # 编译输出目录
├── .env # 环境变量配置
└── package.json # 项目配置文件技术栈
Node.js (ES模块)
TypeScript
@modelcontextprotocol/sdk
Axios
dotenv
许可证
MIT
贡献
欢迎贡献!请提交 issue 或 pull request。
特别感谢小胰宝和 小x宝社区的贡献与付出,用爱心与人工智能为癌症/罕见病患者及其家庭提供支持!
🌟 小X宝公益社区
国内首个面向肿瘤/罕见病/慢性病的AI开源公益社区 AI技术赋能
专注AI+医疗公益应用
成功运营多个肿瘤AI助手(小胰宝、小肺宝等)
拥有丰富的患者服务经验
Available Tools
3 toolsget_rate_limit_statsB
获取当前API速率限制使用情况统计
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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 retrieves current API rate limit usage statistics, implying a read-only operation, but doesn't specify whether it requires authentication, how frequently it can be called, what format the statistics are in, or any potential side effects. This leaves significant gaps in understanding the tool's 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 a single, efficient sentence in Chinese that directly states the tool's purpose without any unnecessary words or fluff. It is front-loaded and appropriately sized for a simple tool with no parameters.
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 (0 parameters, no output schema, no annotations), the description is complete enough to convey the basic purpose. However, it lacks details on output format, authentication needs, or rate limits, which could be helpful for an AI agent. Without an output schema, the description doesn't explain what is returned, leaving a gap in completeness.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, but it could have mentioned that no inputs are required. Given the baseline for 0 parameters is 4, this score reflects that the description adequately handles the lack of parameters without redundancy.
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 verb '获取' (get/retrieve) and the resource 'API速率限制使用情况统计' (API rate limit usage statistics), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like knowledge_recall or knowledge_search, which are unrelated to rate limits, so it misses the highest score.
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 or in what context it should be invoked. It lacks any mention of prerequisites, timing, or comparisons to other tools, leaving usage entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
knowledge_recallB
在Get笔记知识库中召回相关内容,返回未经AI处理的原始结果。可用于快速查找和预览。
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | 要搜索的问题 | |
| topic_id | No | 知识库ID(单个) | |
| topic_ids | No | 知识库ID列表(当前只支持1个)。注意:topic_id和topic_ids可都不提供,如果配置了GET_BIJI_DEFAULT_TOPIC_ID环境变量。优先使用topic_id | |
| top_k | No | 返回相似度最高的N个结果 | |
| intent_rewrite | No | 是否进行问题意图重写 | |
| select_matrix | No | 是否对结果进行重选 | |
| history | No | 对话历史,用于追问场景 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that results are '未经AI处理的原始结果' (raw results without AI processing), which is valuable behavioral context. However, it doesn't disclose other important traits: whether this is a read-only operation, what permissions are needed, rate limits, error conditions, or what the return format looks like (especially problematic since there's no output schema). For a 7-parameter tool with no annotation coverage, this is insufficient.
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 appropriately concise with two sentences. The first sentence states the core purpose and key behavioral trait (raw results). The second sentence provides usage context. There's no wasted text, and the information is front-loaded. It could potentially be more structured with explicit sections, but it's efficient for its 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?
Given the complexity (7 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what the tool returns (critical without output schema), doesn't mention error handling, and provides minimal behavioral context. While it covers the basic purpose and one key trait (raw results), it leaves too many gaps for a tool of this complexity with no structured support from annotations or output schema.
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 100%, so the schema already documents all 7 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no parameter information in the description. The description doesn't compensate or add value here.
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笔记知识库中召回相关内容' (recall related content in Get笔记 knowledge base) with the specific verb '召回' (recall/retrieve) and resource '相关内容' (related content). It distinguishes from sibling 'knowledge_search' by specifying '返回未经AI处理的原始结果' (returns raw results without AI processing). However, it doesn't explicitly contrast with 'get_rate_limit_stats' which serves a completely different purpose.
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 some usage context: '可用于快速查找和预览' (can be used for quick lookup and preview), which implies this is for retrieval rather than analysis or processing. However, it doesn't explicitly state when to use this tool versus 'knowledge_search' (the sibling tool), nor does it mention any prerequisites or exclusions. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
knowledge_searchB
在Get笔记知识库中进行AI增强搜索,返回经过深度处理的答案。支持对话历史追问。
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | 要搜索的问题 | |
| topic_ids | No | 知识库ID列表(当前只支持1个)。如果配置了GET_BIJI_DEFAULT_TOPIC_ID环境变量,可省略此参数 | |
| deep_seek | Yes | 是否启用深度思考 | |
| refs | No | 是否返回引用来源 | |
| history | No | 对话历史,用于追问场景 |
TDQS
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. It mentions 'AI-enhanced search' and 'deeply processed answers', but doesn't clarify what 'deep processing' entails, whether there are rate limits, authentication requirements, or what happens when multiple topic_ids are provided despite the note about current single support. The description adds some context but leaves significant behavioral aspects unspecified.
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 (two short sentences) and front-loaded with the core functionality. Every sentence contributes value, though it could be slightly more structured. There's no wasted verbiage or redundancy.
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 5-parameter search tool with no annotations and no output schema, the description is moderately complete. It covers the core purpose and mentions conversation history support, but doesn't explain the nature of 'AI enhancement', what 'deep processing' means, or what the output format looks like. Given the complexity and lack of structured metadata, more behavioral context would be helpful.
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 100%, so the schema already documents all parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it doesn't explain how parameters interact or provide usage examples. Baseline 3 is appropriate when schema does the heavy lifting.
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 performs 'AI-enhanced search' in the 'Get笔记知识库' and returns 'deeply processed answers'. It specifies the resource (knowledge base) and action (search with AI enhancement). However, it doesn't explicitly differentiate from sibling tools like 'knowledge_recall', which might have overlapping functionality.
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 mentions 'support for conversation history follow-up questions', which implies usage in conversational contexts. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'knowledge_recall', nor does it mention any prerequisites or exclusions for usage.
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.
3 tool updates
- First observed
get_rate_limit_stats - First observed
knowledge_recall - First observed
knowledge_search
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose with no overlap: get_rate_limit_stats handles API monitoring, knowledge_recall provides raw search results, and knowledge_search delivers AI-processed answers. The descriptions make it impossible to confuse these tools as they target fundamentally different operations.
The naming follows a consistent snake_case pattern throughout, but there's a minor deviation in verb style: 'get_' prefix for one tool versus 'knowledge_' prefix for the other two. This small inconsistency prevents a perfect score, though the overall naming remains highly readable and predictable.
With only 3 tools, the set feels thin for a note-taking/knowledge management server, as it lacks basic CRUD operations like creating, updating, or deleting notes. While the tools cover API monitoring and search functions, the scope appears incomplete, making this borderline appropriate.
There are significant gaps in the tool surface for a note-taking server: no tools for creating, editing, organizing, or deleting notes, which are core to the domain. The tools focus only on search and API monitoring, leaving agents unable to perform essential workflows, likely causing failures in typical use cases.
Maintenance
Related MCP Connectors
Recall (recall.it) — your AI knowledge base / 'second brain'. Via the official API: semantic search
Search your knowledge bases from any AI assistant using hybrid RAG.
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
- KnowtisOAuthapp.knowtis
Create, search and manage Knowtis collaborative notes from AI assistants.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables interaction with SiYuan Note through its API for comprehensive note management. Supports searching, creating, editing documents, managing notebooks, and daily notes operations through natural language commands.41 npm15Apache 2.0
- AlicenseNot gradedqualityDmaintenanceIntegrates with Get Notes API to search and retrieve knowledge from configured knowledge bases with AI-powered synthesis and raw recall capabilities.5 npm7ISC
- AlicenseNot gradedqualityDmaintenanceEnables interaction with Rememberizer.ai knowledge repositories to search, retrieve, and store information across sources like Slack, Gmail, and Google Drive. It supports semantic search and agentic queries to access and manage personal or team internal knowledge.Apache 2.0
- AlicenseBqualityAmaintenanceEnables AI models to interact with the Get笔记 (GetNotes) platform via its Open API. It supports managing notes, organizing knowledge bases, and handling tags through natural language commands.241,788 npm90MIT