Loading ToolBench
Hierarchical Markdown knowledge database with MCP access. Provides searchable documentation storage with YAML front-matter support, SQL Server backend, and CLI tools for validation, import, and export.
Three well-named tools (list_children, search_docs, get_doc) with comprehensive descriptions (300-500 chars each) that explain edge cases, semantics, and examples. All tools have input schemas with type declarations and descriptions. However, output schemas are not formally documented in the code, only inferred from return types (IReadOnlyList<DocumentSummary>, SearchResult, DocumentDetail?). No error handling guidance, no parameter constraints (enums), and no tool annotations (readOnlyHint). Descriptions are German-language and verbose but informative. Missing: pagination guidance for list_children (no cap mentioned but 'ggf. >100 Treffer möglich'), output schema documentation, and error recovery hints.
Lädt Titel und Inhalt eines einzelnen Dokuments anhand seines Slugs. Edge Cases: - slug existiert nicht: liefert null (kein Tool-Error) — das LLM hat dann den falschen Slug und sollte list_children oder search_docs erneut aufrufen - Inhalt ist NVARCHAR(MAX) ohne Trunkierung: bei sehr großen Dokumenten kann der Content das Token-Budget des LLM sprengen — ggf. das Dokument in mehrere kleinere Slugs aufteilen - YAML-Front-Matter ist nicht Teil des Contents (wurde beim Import entfernt) Beispiel: - get_doc(slug="it/netzwerk/routing") → DocumentDetail mit title und content - get_doc(slug="unbekannt") → null
Listet die direkten Kind-Dokumente eines Slugs (oder der Wurzel, wenn parentSlug weggelassen oder null ist). Sortierung: alphabetisch nach Slug. Edge Cases: - parentSlug = null oder weggelassen: listet die Root-Dokumente - parentSlug = "" (leerer String): leere Liste, kein Fehler (semantisch identisch zu einem unbekannten Slug) - parentSlug existiert nicht als Dokument: leere Liste, kein Fehler - parentSlug ist kein gültiger Slug (z.B. "Foo Bar"): wird vom Server akzeptiert und liefert eine leere Liste Beispiel: - list_children() → DocumentSummary[] der Root-Dokumente - list_children(parentSlug="it") → DocumentSummary[] der direkten Kinder von "it" - list_children(parentSlug="gibt-es-nicht") → [] Es gibt keine Cap; bei sehr breiten Verzeichnissen sind ggf. >100 Treffer möglich.
Durchsucht Titel, Inhalt, Tags und Synonyme nach einem Suchbegriff (Substring-Match). Liefert die Treffer als SearchResult. Response-Shape: - { results: DocumentSummary[], truncated: bool } - results: Slug + Title der gefundenen Dokumente - truncated: true, wenn es mehr Treffer gibt als MaxResults (Default 50, konfigurierbar via appsettings.json → KnowHowToAi.Search.MaxResults). In dem Fall die Suche verfeinern (präziserer Query) statt alle Treffer zu erwarten. Semantik: - SQL LIKE '%query%' gegen title, content, tags und synonyms - Wildcard-Zeichen (% _ [) im Query werden literal behandelt (Bracket-Escape), kein Wildcard-Smuggling - Sortierung: Title-Treffer zuerst, dann alphabetisch nach title Edge Cases: - query = null/leer/nur Whitespace: leere results, truncated=false - query länger als MaxQueryLength (Default 200, konfigurierbar via appsettings.json → KnowHowToAi.Search.MaxQueryLength): Tool-Error - Keine Treffer: leere results, truncated=false - Viele Treffer (> MaxResults): truncated=true in der Antwort Beispiel: - search_docs(query="netzwerk konfiguration") → { "results": [ {"slug": "it/netzwerk", "title": "Netzwerk"}, {"slug": "it/netzwerk/vlan", "title": "VLAN-Konfiguration"} ], "truncated": false } - search_docs(query="dns") mit >50 Treffern → { "results": [...50 Einträge...], "truncated": true }
Output schemas not formally documented. Return types inferred from C# signatures (IReadOnlyList<DocumentSummary>, SearchResult, DocumentDetail?) but no JSON schema or field descriptions visible in code. LLMs cannot plan downstream tool calls without knowing response structure.
No error handling guidance. search_docs mentions 'Tool-Error' for query length violation but does not specify error response format or recovery steps. get_doc returns null for missing slugs (not an error) but LLM guidance is implicit in description, not explicit in error contract.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All three tools are read-only but this is not declared in tool metadata, LLMs must infer safety from descriptions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | <=2025-11-25 | v2 |
list_children lacks pagination parameters (limit, offset, cursor). Description notes 'Es gibt keine Cap; bei sehr breiten Verzeichnissen sind ggf. >100 Treffer möglich' but provides no way to paginate. Large directory trees will blow context windows.
search_docs response structure (SearchResult with results[] and truncated bool) is documented in description but not in a formal output schema. Field names and types are implicit; LLMs must parse natural language to understand response shape.