BovedIA — sistema de memoria personal para Claude Code: notas Markdown en tu disco, sincronizadas en la nube
BovedIA is a well-intentioned personal knowledge base server with solid domain-specific naming and clear descriptions for most tools. However, it has critical gaps in schema formalization, output documentation, and error handling that prevent it from reaching production-grade quality. Of the 13 tools, 12 have explicit descriptions and reasonable naming following the verb_noun pattern (get_*, create_*, list_*, etc.), but input schemas are inferred from the narrative descriptions rather than formally documented in the code sample provided. Output schemas are completely undocumented across all tools. The server also lacks error recovery guidance, permission gating for destructive operations, and validation error messages that would help LLMs self-correct. The implementation shows thoughtful handling of Unicode normalization (NFC) and Markdown Annotations, but these are implementation details that don't compensate for missing schema and output documentation at the tool interface level.
Añade contenido al final del cuerpo de una nota existente. El método es idempotente: si el contenido ya está al final, no hace nada.
Valida la sintaxis Markdown de una nota: busca wikilinks rotos (como [[Nota No Existe]]) y otros problemas. Útil para mantenimiento de la bóveda.
Crea una nueva nota con el contenido y la ruta especificada. La ruta debe no existir, y el directorio padre debe existir. Se genera automáticamente el frontmatter (YAML) con fecha de creación.
Borra una nota del disco. La nota debe existir. Esta operación es destructiva (la nota se elimina, no se mueve a papelera).
Obtiene el índice completo de la bóveda: lista de notas con su título, tags, y una tabla de backlinks (qué notas enlazan a cuál).
Lee una nota por su ruta relativa. La ruta debe estar dentro de la bóveda y debe existir. Devuelve el contenido de la nota.
Output schemas are completely undocumented. No tool describes what fields it returns, their types, or the structure of the response. This forces LLMs to hallucinate response structures and makes downstream tool chaining fragile. Example: get_index returns 'índice completo' and 'tabla de backlinks' but the actual JSON schema is invisible.
Input schemas are inferred from narrative descriptions, not formally declared in the code. The code sample shows tool descriptions (Spanish-language) but no explicit JSON Schema input validation or registration visible. This makes it unclear whether the SDK-level schemas are formally structured or hand-parsed.
Destructive operations (delete_note, replace_in_note) lack confirmation or dry-run support. No error recovery guidance for accidental deletion. Tool descriptions note destructiveness but provide no pattern for LLM-initiated safeguards.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | 2026-07-28+ | v2 |
Obtiene la lista de todos los tags únicos usados en la bóveda, junto con un recuento de cuántas notas usan cada tag.
Inserta contenido en una posición específica de una nota (después de un marcador). Útil para inserciones precisas sin reemplazar texto existente.
Lista los directorios (subcarpetas) de la bóveda. Útil para navegar la estructura de carpetas y crear notas en directorios específicos.
Renombra una nota (cambia su ruta relativa dentro de la bóveda). La nota actual debe existir, y la ruta nueva no debe existir.
Reemplaza un segmento de texto específico en una nota. El segmento a buscar debe estar presente exactamente una vez. Soporta Markdown Annotations si están habilitadas (KB_ENABLE_ANNOTATIONS).
Añade o reemplaza tags en una nota (se guardan en el frontmatter YAML). Los tags existentes se sobrescriben con los nuevos.
Regenera la tabla de backlinks de la bóveda (qué notas enlazan a cuál). Se ejecuta automáticamente en algunas operaciones, pero puede llamarse manualmente para forzar una actualización.
Error handling is silent. No error responses documented. Example: replace_in_note requires 'oldText' to exist exactly once, but what happens if it's not found, or found twice? The tool description gives no recovery guidance, forcing the LLM to guess or retry blindly.
Parameters lack explicit type validation or constraint documentation. Example: path parameters accept 'ruta relativa' but no regex pattern, max length, or valid-directory-structure constraint is documented. This invites LLM hallucination of invalid paths.
No permission gating documented for any tool. A rogue agent could call delete_note on critical notes without any permission check or audit trail mechanism visible.
No audit logging visible. Tool descriptions and code sample do not show any mechanism to log who called what tool, when, with which parameters, or what happened. This violates compliance and debugging requirements.
Idempotency is partially claimed but not formally enforced. append_to_note claims idempotence but no validation shown. replace_in_note with exact text match is fragile if whitespace or Unicode normalization differs. No explicit per-tool idempotency guarantees.
Tool composition chains are not optimized. Users wanting to 'find notes with tag X and delete them' must call get_tags, then get_index, then delete_note repeatedly. No batch delete or filtered search to consolidate into fewer round trips.