Loading ToolBench
Personal identity exposure and OSINT research system
Daisy Search has 18 well-named tools with consistent verb_noun patterns (daisy_projects, daisy_new_project, daisy_fetch, etc.). All tools have descriptions (avg ~120 chars, within baseline 34-392 range). Input schemas are present and properly typed for all tools. However, output schemas are NOT documented, the code shows tool registration but no return type specifications. Parameter descriptions are present but often terse (e.g., 'Project UUID or name (partial match)' lacks guidance on partial matching rules). Error handling is minimal, no recovery guidance, no categorization of retryable vs fatal errors. Security concerns: the daisy_intake tool accepts arrays of sensitive data (emails, usernames, known facts) with no validation or sanitization guidance visible. The daisy_extract tool calls external APIs (Ollama, Anthropic) but no timeout or failure mode is documented. Overall: solid naming and schema structure, but missing output documentation, error guidance, and security hardening.
Manually add a fact to the active project.
Archive a project (set status to archived).
Rebuild the Neo4j graph for the active project from confirmed facts in Postgres.
Update the lifecycle state of a fact.
Extract facts from a stored source. Tries Ollama, then Anthropic API. If neither available, returns cleaned text for in-context extraction.
Query facts for the active project. Filterable by subject, type, state, confidence.
Fetch a URL and store the raw content as a source.
Output schemas not documented. Tool definitions show input schemas but no return type specifications. LLMs cannot plan downstream calls or extract required fields without knowing what each tool returns.
No error handling or recovery guidance. Tools lack descriptions of failure modes, retryability, or what the LLM should do if a call fails. E.g., daisy_extract tries Ollama then Anthropic API but no timeout or fallback behavior is documented.
Parameter descriptions lack actionable constraints. E.g., daisy_switch_project accepts 'Project UUID or name (partial match)' but does not explain partial matching rules, case sensitivity, or what happens if multiple projects match. daisy_add_fact's 'claim_type' lists values in description but not as an enum.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Fetch a URL (or accept pre-fetched HTML) and return clean extracted markdown. Uses Crawl4AI if available, falls back to trafilatura.
Show fetch attempt history for the active project. Includes auth walls, errors, duplicates, and successes. Use to see what still needs Claude-in-Chrome or retry.
Domain-grouped status report of all fetch attempts for the active project. Call after bulk discovery to see what succeeded, what hit auth walls, and what errored — grouped by site so the user can decide how to proceed.
Query the relationship graph for a subject. Returns all connections.
Add a research subject to the active project. Generates name variants, username guesses, and search queries.
Create a new research project.
List all research projects with their status and stats.
Generate a summary report for the active project or a specific subject.
Run search queries and return candidate URLs. Uses Brave Search or SearXNG.
List fetched sources for the active project.
Switch the active project by ID or name.
Sensitive data handling not documented. daisy_intake accepts arrays of emails, usernames, and known facts with no validation, sanitization, or guidance on PII handling. No audit trail or permission checks visible for destructive operations (daisy_archive_project, daisy_confirm state changes).
Pagination and result limits not consistently applied. daisy_facts, daisy_sources, daisy_fetch_log accept 'limit' but daisy_projects, daisy_search do not. No documentation of default limits or total counts returned, risking context window exhaustion.