The Kibela MCP Server enables interaction with Kibela content via LLMs, providing these capabilities:
Search notes: Use advanced filters like co-editing status, archive status, sort order, user IDs, and folder IDs
Get your latest notes: Retrieve your most recent notes with customizable limits
Get note content and comments: Fetch full content and comments for specific notes
Manage groups and folders: List accessible groups, their folders, and contained notes
Like/unlike notes: Toggle likes on notes and view updated likers lists
List users: Retrieve user details
View note attachments: Access linked attachments
View recently viewed notes: Get your browsing history
Get notes by path: Retrieve notes using paths or full URLs
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., "@Kibela MCP Server search notes about project planning from last month"
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.
MCP server implementation for Kibela API integration, enabling LLMs to interact with Kibela content.
This extension performs GraphQL schema introspection using the buildClientSchema, getIntrospectionQuery, and printSchema functions from the graphql package to reverse engineer Kibela's API.For more details, see her
Search notes with advanced filters
Get your latest notes
Get note content and comments
Manage groups and folders
Like/unlike notes
List users
View note attachments
View recently viewed notes
Get notes by path
Related MCP server: note.com MCP Server
KIBELA_TEAM: Your Kibela team name (required)
KIBELA_TOKEN: Your Kibela API token (required)
Add to your ~/.cursor/mcp.json:
{
"mcpServers": {
"kibela": {
"command": "npx",
"args": ["-y", "@kiwamizamurai/mcp-kibela-server"],
"env": {
"KIBELA_TEAM": "YOUR_TEAM_NAME",
"KIBELA_TOKEN": "YOUR_TOKEN"
}
}
}
}If you want to use docker instead
{
"mcpServers": {
"kibela": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"KIBELA_TEAM",
"-e",
"KIBELA_TOKEN",
"ghcr.io/kiwamizamurai/mcp-kibela-server:latest"
],
"env": {
"KIBELA_TEAM": "YOUR_TEAM_NAME",
"KIBELA_TOKEN": "YOUR_TOKEN"
}
}
}
}Search Kibela notes with given query
Input:
query (string): Search query
coediting (boolean, optional): Filter by co-editing status
isArchived (boolean, optional): Filter by archive status
sortBy (string, optional): Sort by (RELEVANT, CONTENT_UPDATED_AT)
userIds (string[], optional): Filter by user IDs
folderIds (string[], optional): Filter by folder IDs
Returns: List of matching notes with ID, title, URL, author, groups and more
Get your latest notes from Kibela
Input:
limit (number, optional): Number of notes to fetch (default: 15)
Returns: List of your latest notes with author information
Get content and comments of a specific note
Input:
id (string): Note ID
include_image_data (boolean, optional): Whether to include image data URLs in the response (default: false)
Returns: Full note content including HTML, comments, attachments, groups, folders and more
Get list of accessible groups
Input: None
Returns: List of groups with details like privacy settings and permissions
Get folders in a group
Input:
groupId (string): Group ID
parentFolderId (string, optional): Parent folder ID for nested folders
Returns: List of folders with their notes and metadata
Get notes in a group that are not attached to any folder
Input:
groupId (string): Group ID
Returns: List of notes with author information, sorted by last update time
Get notes in a folder
Input:
folderId (string): Folder ID
limit (number, optional): Number of notes to fetch (default: 100)
Returns: List of notes with author information, sorted by last update time
Get list of users
Input: None
Returns: List of users with ID, account and real name
Like a note
Input:
noteId (string): Note ID
Returns: Updated likers list
Unlike a note
Input:
noteId (string): Note ID
Returns: Updated likers list
Get your recently viewed notes
Input:
limit (number, optional): Number of notes to fetch (max 15)
Returns: List of recently viewed notes with author information
Get note content by its path or URL
Input:
path (string): Note path (e.g. '/group/folder/note') or full Kibela URL (e.g. 'https://team.kibe.la/notes/123')
include_image_data (boolean, optional): Whether to include image data URLs in the response (default: false)
Returns: Full note content including HTML, comments, attachments, groups, folders and more
Clone the repository
Install dependencies: npm install
For local development, update your ~/.cursor/mcp.json:
{
"mcpServers": {
"kibela": {
"command": "node",
"args": ["path/to/mcp-kibela-server/dist/src/index.js"],
"env": {
"KIBELA_TEAM": "YOUR_TEAM_NAME",
"KIBELA_TOKEN": "YOUR_TOKEN"
}
}
}
}npx @modelcontextprotocol/inspector node ./dist/src/index.jsand set environemtns
Build and run locally:
docker build -t mcp-kibela-server .Then use this configuration:
{
"mcpServers": {
"kibela": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"KIBELA_TEAM",
"-e",
"KIBELA_TOKEN",
"mcp-kibela-server"
],
"env": {
"KIBELA_TEAM": "YOUR_TEAM_NAME",
"KIBELA_TOKEN": "YOUR_TOKEN"
}
}
}
}For SSE transport, ensure the server URL is set to: http://localhost:3000/sse
Get notes in a folder
| Name | Required | Description | Default |
|---|---|---|---|
| folderId | Yes | Folder ID | |
| limit | No | Number of notes to fetch (default 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether it returns note content metadata, pagination beyond the limit parameter, or sorting behavior. It is too terse for a read operation.
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 with no wasted words. However, it is slightly under-specified for completeness.
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?
No output schema is provided, and the description does not explain what is returned (e.g., full notes or summaries). Missing details on ordering, pagination behavior, and whether subfolder notes are included.
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?
Input schema covers 100% of parameters with descriptions. The description adds no extra meaning beyond the schema, so baseline 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 notes in a folder' clearly indicates retrieving notes from a folder, but lacks scope details. It does not distinguish from sibling tools like kibela_get_group_notes or kibela_search_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 on when to use this tool versus alternatives (e.g., search_notes, get_group_notes). The description does not clarify if this returns only top-level notes or recursively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get folders in a group
| Name | Required | Description | Default |
|---|---|---|---|
| groupId | Yes | Group ID | |
| parentFolderId | No | Parent folder ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only says 'Get folders in a group', omitting details like whether folders are recursive, permissions required, pagination, or return structure. Essential behavior is missing.
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 but at the expense of completeness. It is appropriately short for a simple tool, but lacks necessary context, making it under-specified.
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 output schema and minimal annotations, the description fails to explain what the tool returns (e.g., folder list with fields), how parentFolderId affects results, or any filters. Sibling tools don't compensate.
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?
Both parameters are described in the input schema (100% coverage). The description adds no additional meaning beyond the schema, achieving the 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 clearly states the action (Get) and resource (folders) within a group. It differentiates from sibling tools like kibela_get_group_notes by specifying 'folders', though it could be more precise about the folder hierarchy given the parentFolderId parameter.
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 on when to use this tool versus alternatives such as kibela_get_folder_notes or kibela_get_group_notes. The description does not mention prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get notes in a group that are not attached to any folder
| Name | Required | Description | Default |
|---|---|---|---|
| groupId | Yes | Group ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits such as permissions, error handling, or limitations. The simple statement lacks depth.
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, front-loaded with the action. It is concise, though slightly under-specified; still, no unnecessary words.
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 simple tool with one parameter and no output schema, the description is adequate but incomplete. It does not explain the return format or behavior on error, leaving gaps for the 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?
Schema coverage is 100%, so the description adds no extra meaning beyond the schema. The baseline of 3 applies as the description is not misleading but adds no 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 uses a specific verb ('Get') and resource ('notes in a group') with a qualifier ('not attached to any folder'), clearly distinguishing it from sibling tools like 'kibela_get_folder_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 vs. alternatives, nor any conditions or exclusions. The description simply states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of accessible groups
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'get list', lacking details on pagination, ordering, permission requirements, or whether the list is complete. For a read-only tool, 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 a single concise sentence that front-loads the action and resource, with no unnecessary words.
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 output schema, the description should explain return values. It only says 'list of groups', not what properties each group has (e.g., id, name). This leaves the agent guessing about the response format.
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?
With zero parameters and 100% schema coverage, the baseline is 4. The description adds the purpose ('list of accessible groups') beyond the empty schema, but does not specify any parameter context since none exist.
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' and the resource 'list of accessible groups', making the tool's purpose immediately understandable. It distinguishes itself from sibling tools like kibela_get_group_folders and kibela_get_users.
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 on when to use this tool versus alternatives like kibela_get_group_folders or kibela_get_users. The description does not mention usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your latest notes from Kibela
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of notes to fetch (max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only states the purpose without disclosing behavioral traits such as read-only nature, authentication requirements, rate limits, or result ordering. The description carries the full burden but fails to provide any such details.
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 of five words, front-loaded with the core purpose. Every word earns its place, with no redundancy or unnecessary detail.
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 optional parameter, no output schema), the description is minimally adequate. However, it omits useful context like ordering (e.g., creation date descending) or the set of fields returned, which could help the agent understand the tool's 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?
With 100% schema description coverage, the input schema already fully documents the 'limit' parameter (type, default). The description adds no additional meaning beyond the schema, so 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get your latest notes from Kibela' uses a specific verb ('Get') and resource ('your latest notes'), clearly differentiating it from siblings like 'kibela_search_notes' (search all) and 'kibela_get_recently_viewed_notes' (recently viewed, not owned).
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 implies usage for retrieving the user's own notes but provides no explicit guidance on when to use this tool versus alternatives (e.g., search_notes for broader queries or get_note_content for a single note). No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get content and comments of a specific note
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Note ID | |
| include_image_data | No | Whether to include image data URLs in the response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavioral traits beyond the obvious read operation. Missing details on authentication, rate limits, error handling, or return format expectations for a tool with no output 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?
Single sentence, 6 words, no fluff. Every word is necessary and front-loads the core purpose.
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 output schema, the description should indicate return format or structure (e.g., note object, comments array). It does not, leaving the agent uninformed about what to expect.
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 descriptions for both 'id' (Note ID) and 'include_image_data' (boolean with default). Description adds no additional meaning beyond the schema, meeting baseline.
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 retrieves content and comments of a specific note, using verb 'Get' and resource 'content and comments'. However, it does not distinguish from the sibling tool 'kibela_get_note_from_path', which also retrieves a note by path, missing an opportunity for 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 on when to use this tool versus alternatives (e.g., kibela_get_note_from_path, kibela_search_notes). No conditions described for appropriate use or when not to use.
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 its URL
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Note path (e.g. 'https://${process.env.KIBELA_TEAM}.kibe.la/notes/5154') | |
| include_image_data | No | Whether to include image data URLs in the response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It states it 'gets' content, implying a read operation, but does not confirm idempotency, side effects, or security considerations (e.g., auth required). The description is too minimal.
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, which is concise but lacks important context such as behavioral notes or usage guidance. It is front-loaded but under-specified for a tool with no annotations and no output schema.
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 tool being simple (2 params, no output schema), the description fails to mention what the returned content looks like (e.g., plain text, markdown, metadata). With no output schema, this information is crucial for the agent to process the result.
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 both parameters described clearly in the schema. The description adds no additional semantics beyond the schema, which is acceptable; baseline is 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?
Description clearly states the action (Get note content) and the method (by its URL). This distinguishes it from sibling tools like kibela_get_note_content, which likely uses a note ID. However, it does not explicitly call out the 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 like kibela_get_note_content or kibela_search_notes. No conditions, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your recently viewed notes
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of notes to fetch (max 15) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it's a read operation implicitly. It does not explicitly disclose that it is read-only, or describe any edge cases like empty results or data freshness.
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 that is front-loaded and contains zero unnecessary words. Every word earns its place.
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 optional param, no output schema, no annotations), the description is minimally adequate. It lacks details on return format, ordering, or time scope, but the core purpose is clear.
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% for the single parameter 'limit', which is fully described in the schema. The tool description adds no additional meaning beyond the schema, hence baseline 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 clearly states the action ('Get') and the resource ('your recently viewed notes'), distinguishing it from sibling tools like kibela_get_my_notes by specifying 'recently viewed'.
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 like kibela_get_my_notes or kibela_search_notes. There is no mention of when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of users
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description merely states 'Get list of users' without disclosing any behavioral traits such as side effects, authentication requirements, or return format. The agent has no insight beyond the operation type.
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 but is essentially a restatement of the tool name. It does not earn its place by providing additional value, and it could be more informative without increasing 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 no output schema, the description should explain what the list contains (e.g., IDs, names) and any default behavior. It fails to do so, leaving the agent uncertain about the tool's output.
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?
With no parameters and 100% schema coverage, the description adds minimal value beyond the schema. It states the resource type but does not elaborate on user representation or filtering, so it stays at the baseline 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 list of users' clearly states the verb 'Get' and resource 'list of users', which is precise and distinguishes from sibling tools that deal with folders, groups, or 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 or when to prefer alternatives. The description lacks context about prerequisites or use cases, relying solely on the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Like a note
| Name | Required | Description | Default |
|---|---|---|---|
| noteId | Yes | Note ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits, but it offers none. It does not state side effects, idempotency, permissions, or return behavior. The description adds no value beyond the tool name.
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?
At three words, the description is concise but under-specified. It fails to provide necessary context and does not earn its place with informative content.
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 simple action tool, the description is inadequate. It omits crucial details like what 'liking' entails, effects, error conditions, and any prerequisites. The description is far from complete given the tool's role.
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% for the single required parameter noteId. The schema already describes it as a string with description 'Note ID'. The tool description adds no additional meaning, so 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 'Like a note' essentially restates the tool name 'like_note' without adding specificity or distinguishing it from the sibling 'kibela_unlike_note'. It is a tautology rather than a clear statement of 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?
No guidance is provided on when to use this tool versus alternatives like 'kibela_unlike_note' or other tools. The agent receives no context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Kibela notes with given query
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| coediting | No | Filter by co-editing status | |
| isArchived | No | Filter by archive status | |
| sortBy | No | Sort by (RELEVANT, CONTENT_UPDATED_AT) | |
| userIds | No | Filter by user IDs | |
| folderIds | No | Filter by folder IDs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as pagination, rate limits, or side effects. It does not even state that it is a read operation, leaving the agent without critical 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, but it lacks any additional structure or detail. It is efficient but could include more context without being verbose.
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 having 6 parameters and no output schema, the description fails to explain the return format or search behavior. It is incomplete for a tool of this complexity, as it does not describe what results look like or how filtering works.
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 six parameters. The description adds no additional meaning beyond the schema, earning the 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 clearly states the tool searches Kibela notes with a query, using a specific verb and resource. It distinguishes itself from siblings like kibela_get_note_content which retrieves a single note, and kibela_get_my_notes which is personal.
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 implies usage for searching notes but provides no guidance on when to use this tool versus alternatives like kibela_get_note_content or kibela_get_my_notes. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unlike a note
| Name | Required | Description | Default |
|---|---|---|---|
| noteId | Yes | Note ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral details beyond the basic action. Missing information about idempotency (e.g., what happens if the note is not liked), authorization, or side effects. Annotations are absent, so 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?
Extremely concise (two words), which is efficient but may sacrifice completeness. Could be slightly expanded while remaining concise.
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 simplicity (one param, no output schema), the description is minimal but lacks important context such as idempotency, error conditions, or prerequisites. Additional context would improve 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?
Schema coverage is 100% with a clear description for noteId ('Note ID'). The description adds no additional meaning beyond the schema, but since schema is adequate, 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 'Unlike a note' clearly states the action (unlike) and resource (note), distinguishing it from the sibling tool 'kibela_like_note'. However, it could be more specific (e.g., 'Remove the current user's like from a note').
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 on when or when not to use this tool, or alternatives. The context implies it's for removing a like, but there is no explicit instruction or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.1.0kibela_get_folder_noteskibela_get_group_folderskibela_get_group_noteskibela_get_groupskibela_get_my_noteskibela_get_note_contentkibela_get_note_from_pathkibela_get_recently_viewed_noteskibela_get_userskibela_like_notekibela_search_noteskibela_unlike_noteScored across 12 tools
Most tools have clearly distinct purposes, but some overlap exists between tools that retrieve notes in different contexts (e.g., get_note_content vs get_note_from_path) and between personal note lists (get_my_notes vs get_recently_viewed_notes). Descriptions help disambiguate, so the set is mostly clear.
All tools follow a consistent pattern: 'kibela_verb_noun' with present tense verbs. The naming is uniform and predictable, with no mixing of conventions.
With 12 tools, the count is well-suited for a knowledge management server. It provides a balanced set of read operations, search, and simple interactions without being overwhelming or too sparse.
The tool set is heavily read-only, covering notes, folders, groups, and users, plus like/unlike. However, it lacks essential write operations such as creating, updating, or deleting notes or groups, which limits its completeness for typical workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Create, search and manage Knowtis collaborative notes from AI assistants.
Search, read, create and edit your Memol notes from Claude. Team note-taking with AI search.
Search your knowledge bases from any AI assistant using hybrid RAG.
Connect AI to your flomo notes. Search, create, edit notes and manage tags via MCP.
