Loading ToolBench
MCP server for interkasten — bidirectional Notion sync with adaptive AI documentation
The server registers 25 tools with names, descriptions, and input schemas. However, quality is inconsistent across dimensions. Naming conventions are mostly verb-driven (health, config_get, config_set, sync_start, projects_list, etc.), which is good. Descriptions are present for all tools but vary widely in specificity and depth, many are one-liners (e.g., 'Check health status of interkasten daemon and sync engine') that lack actionable context for LLM tool selection. Parameter descriptions are sparse: many tools have only a single parameter with a brief description (e.g., entity_id: 'Notion ID or local path of entity to triage (optional)'), which is insufficient for the LLM to understand constraints or formats. Output schemas are not documented in the provided source; the source code shows tool registration but does not reveal return types, field names, or pagination support. Error handling patterns are not visible in the sample code provided. Security annotations (destructiveHint, readOnlyHint, idempotentHint) are not present in the source. The server follows a reasonable tool-per-action pattern, but the overall definition quality is hampered by sparse parameter documentation and missing output schema visibility.
Get current interkasten configuration
Update interkasten configuration
List accessible databases in Notion workspace
Get schema of a Notion database
Sync a specific database to local markdown files
Scan Notion workspace for databases and entities
Check health status of interkasten daemon and sync engine
Get hierarchy information for an entity
Output schemas not documented. The provided source does not reveal return types, field names, pagination support, or structured response formats for any of the 25 tools. LLMs cannot plan downstream tool calls or extract the correct data when response structure is undocumented.
Parameter descriptions are sparse and lack specificity. Most parameters have only a brief label (e.g., 'Notion ID or local path of entity') without format constraints, valid ranges, or examples of allowed values. This violates the pattern requirement that every parameter have a non-empty, descriptive annotation explaining what it controls and what format/values are valid.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 56 | - | v1 |
Move an entity within hierarchy (change parent)
Initialize interkasten configuration and database
Create a link between Notion entity and local file
Get linked entities between Notion and local filesystem
Fetch a Notion page with content
Update a Notion page properties and content
Add a new project to tracking
List all tracked projects
Remove a project from tracking
List available signals for event subscriptions
Subscribe to sync signals (events)
Pause ongoing sync operations
Resume paused sync operations
Start manual sync cycle
Get current sync status and queue information
Analyze and diagnose sync conflicts and issues
Get interkasten version and MCP protocol information
Tool descriptions lack context for LLM selection. Many descriptions are under 50 characters and do not answer: What does this tool do? When should I call it instead of a similar tool? What does it return? For example, 'Get current sync status and queue information' does not explain when to call this vs sync_start or sync_pause, or what fields are in the queue response.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present in source code. The server provides a Risk field (READ_ONLY, WRITE, DESTRUCTIVE) in the spec but does not translate these into MCP tool annotations. LLMs cannot distinguish safe read operations from irreversible deletes without explicit annotations.
No pagination support visible for list tools. Tools like projects_list, signals_list, databases_list, and discovery_scan do not expose limit/offset or page_size parameters. Large result sets will blow the context window, and the LLM has no way to fetch paginated results.
Error handling not visible or missing. The sample code does not show error response structures, recovery guidance, or actionable error messages. LLMs have no guidance on what to do when a tool fails (retry, ask user, give up).
Generic parameter names without type suffixes. Parameters like 'entity_id' and 'notion_id' are used interchangeably in some contexts, but are they always interchangeable? The naming does not disambiguate whether a parameter accepts a Notion ID, a local filesystem path, or both. Naming should suffix with the accepted type (e.g., notion_id, local_path, entity_id_or_path) to be explicit.
Destructive operations (projects_remove, pages_update with potential data loss) do not show confirmation or dry-run support. Agents should not silently delete tracked projects or overwrite Notion pages without a confirmation step.
Parameter 'content' in pages_update is marked optional but the description does not explain what happens if omitted. Does it leave the content unchanged? Erase it? Merge with existing? Undocumented dependencies cause silent misuse.