Loading ToolBench
Multi-tenant relay service for HomeKB — pipes requests from remote clients (Web UI, Claude mobile MCP, agents) to home devices over SSE tunnel and streams results back. Zero knowledge-base data at rest.
HomeKB Relay defines 7 tools with complete input schemas and descriptions. Naming follows verb_noun convention (kb_search, kb_read, kb_create, kb_update, kb_list, kb_status, kb_share). Descriptions are substantive (100-200 chars typical), explaining WHAT each tool does and WHEN to use it. All parameters have type definitions and descriptions. However, output schemas are not documented, LLMs cannot predict response structure for downstream chaining. Error handling guidance is absent. The kb_share tool lacks explicit confirmation/dry-run pattern for a sensitive operation (public link creation). Parameter constraints could be more explicit (e.g., enumerate valid doc_type values in kb_search).
Create a new Markdown note in the knowledge base. The filename is derived from the title (or first heading). Returns the created path.
List recent notes in the knowledge base (path, title, type, modified time), newest first.
Read the full Markdown content of a note by its relative path (as returned by kb_search / kb_list).
Semantic search over the user's personal knowledge base (Markdown notes on their home computer). Returns the most relevant chunks/documents with path, title, content and score. Use this first to find existing knowledge.
Create a PUBLIC share link for one note — anyone with the link (and the password, if set) can read it. The note is served live from the user's home computer. Confirm with the user before sharing sensitive content. Returns {url, shareId, expiresAt?}.
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination) for kb_search, kb_read, kb_create, kb_update, kb_list, kb_status, kb_share. This breaks tool chaining, agent cannot extract returned IDs or metadata for downstream calls.
kb_share (public link creation) lacks confirmation/dry-run pattern. Sensitive operation that exposes user content publicly should require explicit user confirmation before executing, not just a description warning.
kb_search 'doc_type' parameter lacks enum constraint. Description says 'see kb_status types' but does not list valid values inline. LLMs cannot self-correct invalid doc_type without calling kb_status first, wasting a round-trip.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
Knowledge base index status: document/chunk counts, pending embeddings, last compile time, known document types.
Overwrite an existing note (full Markdown replacement). Read it first with kb_read to avoid losing content.
No error handling guidance. Tools do not document what errors are retryable, user-fixable, or fatal. E.g., kb_read with invalid path should return 'Note not found. Available paths: [...]' not a bare 404.
kb_list and kb_search lack pagination documentation. No mention of total count, next_cursor, or whether results are capped. Large knowledge bases could return unbounded lists, exhausting context.