Loading ToolBench
The server defines 12 tools with explicit JSON Schema input definitions and basic descriptions. All tools follow a consistent verb_noun naming pattern (kibela_search_notes, kibela_get_my_notes, etc.), which is good for LLM clarity. However, descriptions are uniformly brief (10-40 chars), well below the 50-200 char production baseline, and lack critical context about when to use each tool, what they return, and dependencies between tools. Parameter descriptions are minimal and do not explain constraints, expected formats, or why a parameter matters. Output schemas are completely undocumented, the code calls GraphQL queries and returns response objects, but the tool definitions do not declare what fields the caller should expect. Error handling is absent from the tool definitions. No tool includes guidance on what the LLM should do if the call fails. Overall, the server is functional but cuts corners on description depth and output transparency that production agents depend on.
Get notes in a folder
Get folders in a group
Get notes in a group that are not attached to any folder
Get list of accessible groups
Get your latest notes from Kibela
Get content and comments of a specific note
Get note content by its URL
Tool descriptions are uniformly 18 - 40 characters, well below the 50 - 200 char production baseline. Descriptions lack WHEN to use the tool, WHAT it returns, and dependencies on other tools. Examples: 'Like a note' (12 chars), 'Get list of users' (17 chars), 'Get list of accessible groups' (29 chars). LLMs cannot distinguish similar tools or understand return structure from these stubs.
Parameter descriptions are minimal or absent. For example, kibela_search_notes accepts 'sortBy' with description 'Sort by (RELEVANT, CONTENT_UPDATED_AT)', this is a constraint, not a description explaining when/why to use it. Parameters lack guidance on expected format, valid ranges, or dependencies. Example: 'limit' in kibela_get_my_notes says 'Number of notes to fetch (max 50)' but does not explain what happens if you request >50, or recommend a good default for typical use.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get your recently viewed notes
Get list of users
Like a note
Search Kibela notes with given query
Unlike a note
Output schemas are completely undocumented. Tools define input schemas but do not describe what the response contains. For example, kibela_search_notes calls GraphQL SearchNotesQuery and returns SearchResponse (a TypeScript type), but the tool definition does not declare the fields in SearchResponse, their types, or which fields are required downstream. LLMs must guess what data to extract, risking missed fields needed for chaining (e.g., if the next tool needs 'note_id', but the response uses 'id' or 'noteId').
No error handling guidance in tool definitions. If a query fails (e.g., 'note not found', 'permission denied', 'API rate limit'), the code returns an error but the tool definition provides no recovery instructions. LLMs cannot determine if the error is retryable, if they should ask the user, or if the operation is impossible.
Destructive tools (kibela_like_note, kibela_unlike_note) lack state-modifying hints. The tool definitions do not declare that these are WRITE operations with side effects. Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are absent, preventing the LLM from treating these tools with appropriate caution.
No pagination guidance in tool definitions. Tools like kibela_search_notes, kibela_get_my_notes, and kibela_get_folder_notes accept 'limit' parameters but do not document whether results are paginated, whether there is a cursor or offset, or how to fetch the next batch. Without pagination metadata, agents cannot safely iterate over large result sets.
Parameter 'include_image_data' in kibela_get_note_content and kibela_get_note_from_path lacks description of what 'image data URLs' means. Is this base64-encoded inline images, URIs to image assets, or HTML fragments? LLMs cannot decide whether to request this without understanding its format and size implications.