Loading ToolBench
Agent memory with deletion guarantees. Provides governed memory for MCP agents with compliance, lineage tracking, and GDPR-compliant data erasure.
Orenyl defines 14 tools with complete input schemas and descriptions. Naming follows verb_noun patterns (store_event, retrieve_context_pack, delete_and_recompute). Descriptions are substantive (100-250 chars) and include use-case context. However, parameter descriptions are sparse or missing entirely, most params lack guidance on format, constraints, or when to use them. Output schemas are not documented anywhere in the source. Error handling and recovery guidance are absent. The server targets a specialized domain (governed memory, GDPR compliance) with sophisticated concepts (lineage, soft/hard deletion, sensitivity levels), but the tool interface does not guide LLMs through these nuances. Schemas are well-formed JSON Schema with enums and defaults, but lack descriptions for individual parameters.
Scan audit events for suspicious access patterns over a recent window.
Get full lineage trace for an event or fact. Use include_source_events=true for drill-down into raw contributing events.
Create a database-wide DR snapshot in single-tenant deployments.
Delete an event or fact and recompute downstream lineage. Use mode='soft' for reversible governance deletion and mode='hard' for physical erasure/audit compliance. Example: delete_and_recompute(target_id='event:...', target_type='event', mode='hard').
Erase all active subject-linked records and cascade recompute with deletion proof.
Export complete domain data for right-to-access workflows. Returns events, facts, and lineage edges in json, markdown, or timeline format.
Parameter descriptions missing or minimal. Most params (e.g., 'mode', 'reason', 'window_minutes') lack guidance on format, valid values, or when to use them. LLMs cannot infer whether 'mode' means 'soft' vs 'hard' deletion without explicit description.
Output schemas not documented. Tools return complex structures (lineage traces, domain exports, processing records) but no schema is provided for LLM planning. Agents cannot know what fields to expect or how to chain results to downstream tools.
No error handling or recovery guidance. Tools like delete_and_recompute and erase_subject_data are destructive but provide no confirmation step, dry-run mode, or error classification. Agents cannot distinguish retryable from fatal failures.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
Export all active subject-linked records with deterministic integrity manifest.
Generate Article 30-style data processing record for the tenant.
List events with domain filtering and pagination for full-history review. Use include_tombstoned=true for compliance/audit views.
Record consent status changes for a subject and processing purpose.
Restore a database-wide snapshot in single-tenant deployments.
Retrieve bounded personal context for a domain before using its own memory. Returns facts, summary, and retrieval metadata filtered by sensitivity. Example: retrieve_context_pack(domain='health', query='what meds am I on?').
Store important personal facts the user shares (health, career, finance, relationships, preferences, decisions). Use this when the user reveals new personal context that should be durable and auditable. Example: store_event(domains=['health'], type='med_started', payload={'name':'metformin'}).
Verify a database-wide snapshot checksum in single-tenant deployments.
Compound tool names. 'delete_and_recompute' combines two actions (delete + recompute lineage). Should split into separate tools so agents can compose them independently.
generate_processing_record has empty input schema (no properties). Unclear what parameters it accepts or whether it requires configuration. Schema score capped at 40.