Loading ToolBench
MCP stdio shim for Kryton — bridges stdio JSON-RPC to a Kryton server's /api/mcp HTTP transport
Kryton MCP provides 24 well-structured tools for knowledge base management with consistent naming conventions and comprehensive descriptions. All tools have explicit JSON Schema input definitions with type declarations and parameter descriptions. Naming follows the verb_noun pattern (list_*, read_*, create_*, update_*, delete_*, search_*) which is clear and LLM-friendly. Descriptions are present and actionable (ranging 45-180 chars), explaining what each tool does and when to use it. However, there are systematic gaps: (1) No documented output schemas for any tools, critical for composition and chaining; (2) Missing error handling guidance, no recovery steps or categorization; (3) No pagination parameters on list_* tools despite returning variable-length results; (4) Parameter descriptions could be more precise regarding constraints (e.g., path format, character limits); (5) No security/permission declarations visible; (6) No tool annotations (readOnlyHint, destructiveHint) to guide agent planning. The server demonstrates solid fundamentals but lacks production-grade polish in output documentation and error guidance.
Star a note (add it to favorites). No-op if already favorited.
Append markdown content to the end of an existing note. Adds a leading blank line if the note doesn't end in one.
Create a new folder in the knowledge base.
Create a new markdown note.
Create a new note from an existing template.
Delete a note by its path.
No output schemas documented for any of the 24 tools. LLMs cannot infer what fields are returned, breaking composition patterns and forcing agents to guess at response structure.
list_* tools (list_notes, list_tags, list_folders, list_templates, list_favorites, list_recent_notes, list_daily_notes) lack pagination parameters (limit, offset, page_size) and return field documentation. Without explicit limits, large result sets can exhaust context windows.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 74 | 2026-07-28+ | v2 |
Get all notes that contain wiki-links pointing to the given path.
Get today's daily note. Returns the note content if it exists, or indicates it doesn't exist yet.
Get the full wiki-link graph with nodes (notes) and edges (links between them).
Get a note's title + modifiedAt + size without pulling the full content. Cheap discovery.
List all daily notes (Daily/YYYY-MM-DD.md), newest first.
List the paths of notes the user has starred / favorited.
List the folder structure of the knowledge base.
List all notes in the knowledge base. Returns paths and titles.
List notes that contain a given tag. Returns paths + titles.
List notes sorted by most-recently-modified first. Useful for 'what was I working on' queries.
List all tags used across notes with their counts.
List available note templates.
Read a note's markdown content by its path.
Unstar a note. No-op if not currently favorited.
Rename or move a note. Updates wiki-links + tag/search indexes atomically.
Full-text search across all notes. Returns matching paths, titles, and snippets.
Update a note's content (full replacement). Read the note first to get current content.
Create or replace today's daily note (at Daily/YYYY-MM-DD.md). Use append_to_note instead if you want to add to existing content without overwriting.
No error handling guidance visible. Tools like delete_note and update_note are destructive but provide no recovery instructions or error classification. LLMs cannot determine if errors are retryable, user-fixable, or fatal.
No tool annotations visible (readOnlyHint, destructiveHint, idempotentHint). Tools that modify state (create_*, update_*, delete_*, append_*, write_*, add_*, remove_*) should be marked destructiveHint=true to guide agent planning and prevent accidental data loss.
Parameter descriptions lack specificity about constraints. 'path' parameters accept values like 'folder/my-note.md' but descriptions do not clarify path format, allowed characters, max length, or escaping rules. This invites LLM errors with special characters or malformed paths.
rename_note accepts oldPath and newPath but does not describe what happens if newPath already exists (overwrite, conflict, error?). Ambiguous behavior invites unintended overwrites.
list_recent_notes has a 'limit' parameter with default 20, but schema shows it is not required and no min/max bounds are specified. Agents could pass unbounded large values causing performance issues.
No permission/scope declarations visible. Tools like delete_note, create_note, and update_note lack explicit statements of what permissions are required (e.g., 'write:notes', 'admin:knowledge-base'). This prevents least-privilege agent configuration and audit clarity.