Loading ToolBench
Personal knowledge database that automatically retrieves stored personal context when needed for personalized responses. Captures and stores personal information when user shares details. Triggers on: 'my [anything]', personal questions, preference queries, or when personal context would improve responses.
DataDam MCP has 7 tools with generally clear descriptions and attempt at schema definition, but significant gaps in parameter documentation and output schemas. Tools have descriptive names starting with action verbs (search-, extract-, create-, update-, delete-, fetch) and descriptions are reasonably detailed (150-400 chars typical), meeting baseline expectations. However, 2 of 7 tools (search, fetch) have minimal or inferred definitions based on file references rather than explicit registration code shown. Input schemas use Zod validation, providing some type safety, but descriptions lack consistency in explaining parameter relationships and valid constraints. Output schemas are entirely undocumented, LLMs have no visibility into return structures, forcing inference. Error handling is present but basic. Security considerations around PII storage are acknowledged but not explicitly validated in tool definitions. Overall, the server demonstrates moderate quality typical of community databases (C+ range), but falls short of production-grade tool composition (B/A range).
Capture and store personal data when user shares information about themselves. The user's AI tool settings determine whether to store automatically or ask for consent first.
Remove personal data records. Requires record UUID(s) from previous search/extract. Use when user explicitly wants to delete information.
Update existing personal data records. Modify specific fields or full records.
Retrieve items by CATEGORY or TAGS when browsing/listing without specific search terms. Use for "show me all my X" requests or tag-based filtering. Returns complete records.
Retrieve complete document content by ID including full text, metadata, and all associated information.
Search through personal data by matching against title, tags, and categories only (not content). Returns citation-friendly results.
Two tools (search, fetch) have minimal or inferred definitions. Only file paths provided ('src/database/schema.sql', 'src/tools/chatgpt-fetch.ts'); no explicit registration code visible in provided source. Search lacks category/tag/classification parameters shown in search-personal-data; fetch lacks input schema documentation entirely.
Output schemas completely undocumented. Tools return data (search results, extracted records, confirmation messages) but no schema definitions provided. LLMs cannot plan downstream calls or extract typed fields. All tools affected.
Naming inconsistency: 3 tools use 'datadam_' prefix (datadam_create_personal_data, datadam_update_personal_data, datadam_delete_personal_data) while 4 do not (search-personal-data, extract-personal-data, search, fetch). Inconsistent prefixes increase LLM confusion when selecting from a tool list.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Search for SPECIFIC datapoints, names, or details across all personal data using keyword matching. Use when looking for a specific person, thing, or piece of information (e.g., "find John's email", "my passport number", "Docker info"). Returns ranked results with context snippets.
Parameter 'response_format' in create, update, delete tools allows enum ['json', 'markdown'] but no guidance on when to use each or what downstream tools expect.
extract-personal-data requires 'category' but parameter description only lists available values without explaining when/why to pick each. Guidance like 'Use contacts for people, books for reading lists' would improve LLM selection.
datadam_update_personal_data expects 'recordId' (UUID) but users do not have UUIDs in conversation context. Tool description says 'Obtain from datadam_search_personal_data or datadam_extract_personal_data first' but search/extract tools shown do not explicitly document that they return recordId. Broken composition chain.
No error handling documentation. Tools lack guidance on retryable vs non-retryable failures, missing resources vs permission denials, or expected error messages.
Destructive tool (datadam_delete_personal_data) accepts hardDelete flag defaulting to false, which is good, but no confirmation/dry-run mechanism documented. Agents make mistakes, no safeguard pattern visible.
Parameter descriptions include example values (e.g., 'Examples: john email, passport, TypeScript') which LLMs often reuse literally. Rubric section B advises against this; use enums or constraints instead.
search-personal-data has 'userId' parameter marked optional. Tool description does not explain what happens when userId is omitted, is it required for multi-user systems? Does it default to a session user? Undocumented dependency.