Telegram-bot knowledge base for forwarded content with MCP server integration for hybrid search, note management, and attachment handling
Soroka exposes 9 tools for knowledge base search and retrieval. All tools are read-only except delete_note (destructive). Tool names follow verb_noun convention consistently (search, get_by_id, list_recent, get_attachment, delete_note, find_similar, get_context, get_by_ids, stats). Descriptions are present and moderately detailed (average ~80 chars). However, several parameters lack descriptions, and output schemas are not documented in the source. The delete_note tool references audit logging and soft-delete semantics but provides no recovery mechanism or confirmation pattern. Pagination support is present in search (limit, offset) and list_recent (limit), though not all list operations document per-item success/failure handling.
Soft-delete a note. The row stays for possible recovery via raw SQL; everything user-facing hides it. Reason is logged for audit.
Find notes similar to a given note using semantic search.
Get the first attachment for a note, returned as base64-encoded content.
Retrieve a single note by ID.
Retrieve multiple notes by their IDs.
Get notes surrounding a given note in the channel timeline (temporal context window).
Output schemas not documented. Tools return data but LLMs cannot see what fields to expect, forcing trial-and-error exploration. search() might return note_id, content, kind, created_at, but this is inferred, not declared.
delete_note lacks confirmation/dry-run pattern. No protection against irreversible data loss. LLMs can be tricked into deleting important notes. Soft-delete is good, but no recovery mechanism documented.
Several parameters lack descriptions: get_attachment(note_id) description says 'The note ID to retrieve attachment for' but does not explain return format (base64), possible errors (no attachment), or encoding. stats() takes no parameters but no output structure documented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
List recent notes, optionally filtered by kind and time window.
Hybrid search over the knowledge base. Explicit kind/since_days bypass LLM intent detection.
Get statistics about the knowledge base: total notes, notes per kind, time range, activity by period.
get_context(window=3) default is undocumented. Does window=3 mean 3 before+3 after (6 total) or 3 total? No min/max bounds specified. LLMs might request window=1000, causing performance issues.
Error handling not documented. What happens if note_id is invalid? Does get_by_id return null, throw 404, or return an error object? No recovery guidance.