Personal knowledge server - semantic search, persistent memory, and proactive insights for your documents
Textrawl provides 20 tools with mostly complete naming and descriptions, but several critical gaps in schema documentation, parameter validation, and error handling. Tool names follow verb_noun conventions (ask, search, capture, remember), which is good for LLM clarity. However, many tools lack detailed input parameter descriptions and output schema documentation. Error handling is minimal, tools do not guide recovery or classify errors. Schema completeness varies: some tools have basic type information, but descriptions of what fields are returned are absent from source code inspection. The server uses HTTP transport (Express), which is current-spec compliant. Resources feature is implemented, but tool annotations (readOnlyHint, destructiveHint, idempotentHint) are missing entirely, forcing LLMs to infer side effects.
Add a URL to your knowledge base (fetches and indexes content)
Ask questions about your knowledge base with semantic search and citations
Generate a briefing or summary of documents
Capture and store a new piece of information or document snippet
Retrieve a specific conversation with all turns
List conversation sessions
Start a new conversation session
Create a new note in the knowledge base
Missing tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools with side effects (capture, update_document, create_note, add_url, remember, memory_add, conversation_start) are not marked as destructive. LLMs cannot determine which tools are safe to retry without explicit annotations.
Output schemas not documented in source code. Tools return results but no explicit schema definition is visible for what fields are included (e.g., ask/search return hits with score and content, but this structure is not declared in the handler registration). Without documented output schemas, LLMs cannot plan downstream tool invocations reliably.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Retrieve a specific document by ID from your knowledge base
Check the health status of the Textrawl server
List generated insights
Get statistics about your knowledge base
List all documents in the knowledge base
Add a memory observation
List all stored memories
Analyze PostgreSQL database performance and health
Store a memory or observation about entities
Search your knowledge base using semantic similarity
Generate a timeline view of events from your documents
Update metadata or content of an existing document
Inconsistent parameter descriptions. Tools like 'briefing' and 'timeline' have minimal parameter documentation (only query string noted, no format/length constraints or examples of expected input). Parameter descriptions should explain format, constraints, and prerequisites per pattern:tool-description.
No pagination guidance in source. Tools like list_documents and memory_list accept 'limit' and 'offset' parameters, but no maximum limit is enforced or documented. LLMs may request thousands of items, exhausting context. Should enforce cap (e.g., max 50) and document in description.
Error handling not visible in tool definitions. No indication of which errors are retryable, user-fixable, or fatal. Tools do not provide recovery guidance (e.g., 'User not found, try search_users() first'). Error responses should be structured and actionable per pattern:recovery-guide.
No explicit idempotency guarantees. Tools that modify state (capture, create_note, remember, memory_add) do not declare idempotent behavior. If an agent retries due to a network timeout, these tools may create duplicates. Add idempotentHint annotation and document duplicate detection strategy.
Parameter type definitions incomplete. Several tools lack explicit JSON Schema type declarations for parameters. E.g., 'tags' in capture is described as array but no itemType or minItems/maxItems constraints visible. All parameters should have type, description, and validation constraints.