The MCP Kibela server enables AI assistants to interact with Kibela content through various operations:
Search Kibela notes: Search for notes using keywords or queries
Fetch personal notes: Retrieve your latest notes, with optional limits
Get note content: Access content and comments of a specific note by ID or path
Create new notes: Create notes with options for title, content, folders, author, groups, and co-editing
Update note content: Modify existing notes by ID
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 Kibela search for notes about quarterly planning"
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.
A Model Context Protocol (MCP) server implementation that enables AI assistants to search and reference Kibela content. This setup allows AI models like Claude to securely access information stored in Kibela.
The mcp-kibela server provides the following features:
Note Search: Search Kibela notes by keywords
My Notes: Fetch your latest notes
Note Content: Get note content and comments by ID
Note by Path: Get note content by path
Create Note: Create a new note
Update Note Content: Update note content by note id
Related MCP server: HackMD MCP Server
Before you begin, ensure you have:
Node.js (v18 or higher)
MCP Client (Claude Desktop, Cursor, etc.)
Kibela Access Token (How to get a token)
Git (if building from source)
{
"kibela": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"KIBELA_TEAM",
"-e",
"KIBELA_TOKEN",
"ghcr.io/kj455/mcp-kibela:latest"
],
"env": {
"KIBELA_TEAM": "your-team-name from https://[team-name].kibe.la",
"KIBELA_TOKEN": "your-token"
}
}
}{
"mcp": {
"inputs": [
{
"type": "promptString",
"id": "kibela_team",
"description": "Kibela team name",
"password": false
},
{
"type": "promptString",
"id": "kibela_token",
"description": "Kibela token",
"password": true
},
],
"servers": {
"kibela": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"KIBELA_TEAM",
"-e",
"KIBELA_TOKEN",
"ghcr.io/kj455/mcp-kibela:latest"
],
"env": {
"KIBELA_TEAM": "${input:kibela_team}",
"KIBELA_TOKEN": "${input:kibela_token}"
}
}
}
}
}{
"mcpServers": {
"mcp-kibela": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"KIBELA_TEAM",
"-e",
"KIBELA_TOKEN",
"ghcr.io/kj455/mcp-kibela:latest"
],
"env": {
"KIBELA_TEAM": "your-team-name from https://[team-name].kibe.la",
"KIBELA_TOKEN": "your-token"
}
}
}
}npx -y @smithery/cli install @kj455/mcp-kibela --client claudeThe following environment variables are required:
KIBELA_TEAM: Your Kibela team name (required). You can find it from the URL of your Kibela team page. e.g. https://[team-name].kibe.la
KIBELA_TOKEN: Your Kibela API token (required)
Any contributions are welcome!
Use npm run build:watch to build the project in watch mode.
npm run build:watchUse npx @modelcontextprotocol/inspector to inspect the MCP server.
npx @modelcontextprotocol/inspector node /path/to/mcp-kibela/dist/index.jsMIT
Create a new note in Kibela.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | required: Title of the note | |
| content | Yes | required: Content of the note in markdown format | |
| groupIds | No | required: IDs of the groups to create the note in. | |
| folders | No | IDs of the folders to add the note to. | |
| authorId | No | ID of the author of the note. If not specified, the note will be created by the authenticated user. | |
| coediting | No | required: Whether to enable co-editing for the note | |
| draft | No | Whether to create the note as a draft |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is minimal and does not disclose behavioral traits such as permissions required, side effects, or rate limits. With no annotations, the description should provide more context.
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 concise sentence. It is appropriately sized but could benefit from a slightly more structured presentation.
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?
The tool creates a resource but lacks any mention of what the output or return value is. The absence of an output schema increases the need for description coverage, which is missing.
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 covers 100% of parameters with descriptions, so the baseline is 3. The tool description adds no additional meaning beyond what the schema already provides.
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 action ('Create') and the resource ('a new note in Kibela'). It differentiates from sibling tools which are focused on retrieval, search, or update.
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 explicit usage guidance is provided. The purpose implies it is for creating notes, but there is no mention of when to use it versus alternatives like searching or updating.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get my latest notes from Kibela
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of notes to fetch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It implies a read operation but does not disclose what constitutes 'latest' (e.g., creation time vs update time), whether authentication is needed, or what the response format looks like. This leaves significant behavioral gaps.
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?
A single sentence of 5 words conveys the purpose efficiently. No extraneous information; the action is front-loaded.
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?
Despite the simple parameter, the description fails to explain the structure of 'notes', the meaning of 'latest' (e.g., sorting order), or any pagination behavior implied by the limit parameter. With no output schema or annotations, the tool lacks sufficient detail for reliable agent use.
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 coverage is 100% with the 'limit' parameter clearly described in the schema. The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
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 'Get my latest notes from Kibela' clearly states the specific verb 'Get', the resource 'my latest notes', and the system 'Kibela'. It distinguishes from siblings like kibela_search_notes (search) and kibela_get_note_content (specific note content) by focusing on personal and recent notes.
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 does not mention when to prefer this over kibela_search_notes or kibela_get_note_from_path, nor does it specify any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get note content by note ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Note ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden for behavioral disclosure. It only states the basic action without detailing what is returned (e.g., full note content vs. metadata), whether authentication is needed, or error handling for invalid IDs. This is insufficient for a tool that likely requires certain permissions.
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 very short (one sentence) and directly to the point. While it lacks structure (e.g., sections or bullet points), its brevity is acceptable for a simple tool. No unnecessary words are present.
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 (one required parameter, no output schema), the description is minimally adequate. However, it could be improved by specifying what the response contains (e.g., 'Returns the note content as a string') and noting potential errors. Overall, it covers the essential purpose but not the full context.
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 coverage is 100% (the parameter 'id' has a description 'Note ID'). The description reiterates this with 'by note ID', which adds no new meaning. Baseline score of 3 is appropriate since the schema already provides the necessary detail.
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 explicitly states the action ('Get'), resource ('note content'), and identifier ('by note ID'). It clearly distinguishes from sibling tools like 'kibela_create_note' (create), 'kibela_search_notes' (search), and 'kibela_get_note_from_path' (different retrieval method).
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. There is no mention of use cases, such as retrieving full content versus summaries from 'kibela_get_my_notes', or when to prefer path-based retrieval via 'kibela_get_note_from_path'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get note content by note path
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Note path (e.g. /notes/123) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only implies a read operation ('get') but does not explicitly state that it is read-only, has no side effects, or any prerequisites. The minimal description leaves behavioral traits underspecified.
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 one front-loaded sentence that clearly states the purpose. Every word is essential, no 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?
Given the tool's simplicity (1 param, no output schema), the description covers the basic action but lacks details about return value or behavior. For a fully complete description, it should mention what the output contains (e.g., note content as text).
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% for the single 'path' parameter, with an example provided. The description adds no additional meaning beyond the schema, leading to a baseline score of 3.
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 'Get note content by note path' specifies a clear verb (get), resource (note content), and method (by path). It distinguishes from siblings like kibela_get_note_content (likely by ID) by emphasizing the path-based retrieval.
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 implicitly indicates use when a note path is available, but lacks explicit guidance on when not to use or alternatives (e.g., if note ID is known, use kibela_get_note_content instead). This is a missed opportunity for clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Kibela notes by query
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is expected to disclose behavioral traits. It only states the basic function without explaining what the output looks like, whether it is read-only, or any limitations. This is insufficient for an agent to predict 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 sentence and front-loaded with the purpose. However, it is overly brief and lacks context that would improve usability without adding much 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 lack of an output schema, the description should at least hint at the return format (e.g., list of note titles or full content). It also does not mention any limitations like pagination or search scope, leaving the tool incomplete for an 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 input schema has 100% coverage with a single parameter described as 'Search query'. The description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.
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 (search) and resource (Kibela notes), and the query parameter is implied. However, it does not differentiate from sibling tools like 'kibela_get_my_notes' or 'kibela_get_note_content', which could lead to confusion about scope.
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. There is no mention of when to search versus fetch specific notes or lists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update note content by note id. This tool allows you to modify the content of an existing Kibela note. Before updating, it fetches the current content of the note to ensure proper version control. Note that you need the note ID (not the note path) to use this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Note id - not note path (e.g. /notes/123). If you want to update note content by note path, please use kibela_get_note_from_path tool first and get note id from the response | |
| content | Yes | New content of the note in markdown format. The content will completely replace the existing note content. Make sure to include all necessary formatting, headers, and sections you want to preserve. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It reveals that tool fetches current content before updating for version control, which is a key behavioral trait. However, it could mention error handling or idempotency. On balance, adds value beyond schema.
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?
Description is three concise sentences, no redundancy. Front-loaded with purpose. Could be slightly more structured but is efficient and readable.
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, description covers key aspects: update action, pre-fetch, and parameter requirements. However, it lacks information about return value or error scenarios, leaving some gaps for an agent to understand full behavior.
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%, baseline 3. Description adds significant context: for 'id', explains difference from path and workflow; for 'content', specifies markdown format and replacement semantics. This enhances understanding beyond the schema.
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?
Description clearly states it updates note content by note id. It distinguishes from sibling tools like kibela_create_note, kibela_get_note_content, and kibela_search_notes by specifying the update action and the requirement of note ID.
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?
Explicitly tells when to use this tool (when you have note ID) and provides guidance for note path users: use kibela_get_note_from_path first. Also mentions the pre-fetch step for version control, indicating expected usage pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: creating, retrieving by ID or path, listing personal notes, searching, and updating. No overlap or ambiguity.
All tools follow a consistent 'kibela_verb_noun' pattern (e.g., kibela_create_note, kibela_search_notes), maintaining Convention throughout.
6 tools is well within the ideal 3-15 range, covering the core note operations without being overengineered or sparse.
The set covers create, read (multiple methods), search, and update, but notably lacks a delete note tool, and does not provide a simple 'list all notes' functionality. This leaves a gap in full CRUD coverage.
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…
A Model Context Protocol server for Wix AI tools
Google Keep-style notes app with an MCP server for AI agents to read/write notes.
Model Context Protocol server for Studex tools, notifications, and profile integrations
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kj455/mcp-kibela'
If you have feedback or need assistance with the MCP directory API, please join our Discord server