Loading ToolBench
Memory integrity for DataHub agents — agent memories that expire when the data beneath them changes.
Half-Life defines 5 tools with complete input schemas and descriptions. Naming is verb-forward (recall, record_memory, validate_memories, explain_memory, memory_ledger) and action-clear. Descriptions are domain-specific and contextual (avg ~180 chars), exceeding the 10 - 1024 char baseline. All parameters have type definitions and descriptions. However, output schemas are not formally documented in the tool definitions, responses are inferred from code inspection. Error handling is present but minimal (e.g., record_memory returns {"error": ...} without recovery guidance). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk profiles (READ_ONLY vs WRITE). Parameter descriptions lack format constraints (e.g., URN format, query syntax). Tools are well-composed and single-purpose, but output structure documentation is missing from the MCP schema layer.
Show a memory's provenance and why it holds its current status.
Every memory with its current integrity status.
Retrieve previously learned facts that are still trustworthy. Expired memories are never returned. Suspect memories come back with a warning describing what changed beneath them.
Store a conclusion so future agents inherit it. `dependencies` must list every DataHub URN the conclusion rests on — datasets, schema fields or glossary terms. They are what allow the memory to be invalidated later, so a memory recorded without them cannot be protected.
Re-check memories against the current state of their dependencies. Returns every state transition. With `apply`, verdicts are written back to DataHub: expired memories are unpublished so they can no longer be recalled.
Output schemas not documented in tool definitions. LLMs cannot plan downstream calls or extract fields without seeing the response structure. Code inspection reveals complex nested objects (memories array with urn/title/text/status/integrity_score/dependencies/warning fields), but this is not declared in the MCP schema.
No tool annotations despite clear risk profiles. record_memory and validate_memories are destructive (WRITE risk), but lack destructiveHint annotation. recall, explain_memory, memory_ledger are READ_ONLY but lack readOnlyHint. Agents cannot distinguish safe from unsafe tools without reading descriptions.
Error handling lacks recovery guidance. record_memory returns {"error": "dependencies must not be empty"} but does not suggest what to do next. explain_memory returns {"error": "No memory found at {urn}"} without offering alternatives (e.g., 'Try recall() to search for similar memories').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Parameter descriptions lack format constraints. 'dependencies' is described as 'List of DataHub URNs' but URN format is not specified (e.g., 'urn:li:dataset:(urn:li:dataPlatform:...,...)' or similar). 'query' in recall lacks syntax hints (e.g., 'free-text search or structured query syntax').
memory_ledger tool has empty input schema ({}). While this is valid, the description does not explain what 'every memory' means (all in the store? paginated? filtered by status?). No pagination parameters despite potential for large result sets.