Imprint has well-structured tool definitions with explicit schemas and descriptions. All 10 tools are registered with names, descriptions, and input schemas using jsonschema tags. However, descriptions are domain-specific and assume deep familiarity with the 'imprint' policy vault system; they lack clarity for general LLM agents unfamiliar with the domain. Parameter descriptions are present but often terse (e.g., 'rule id from find' for the 'id' param in get/forget). Output schemas are not documented, callers must infer structure from code. Error handling is minimal; tools return toolErr() but guidance on recovery is absent. No tool annotations (readOnlyHint, destructiveHint) are present despite clear risk levels (DESTRUCTIVE for forget, WRITE for add/reinforce/supersede/link/sweep). Naming is verb-first and clear (find, add, reinforce, supersede, link, forget, get, list, show, sweep), following conventions well.

• Add output schema documentation to each tool. Document the structure of find (returns rules with id, claim, scope, confidence, evidence, sources), add (returns rule id and advisory conflicts), list (returns array of rule summaries with pagination), etc. This enables agents to plan multi-step workflows.
• Annotate tools with risk hints: add readOnlyHint=true to find/get/list/show; destructiveHint=true to forget; idempotentHint=true to reinforce (if repeated calls with same evidence are safe). This signals to agents which operations are safe to retry.
• Rewrite descriptions for clarity. Example: find should say 'Search the policy vault for rules matching a query. Use this to recall existing policies before adding or modifying rules. Returns rule summaries with confidence scores.' instead of 'Recall rules and optional shelves documents.'
• Enhance error messages with recovery guidance. When a rule is not found, return 'Rule not found. Try find() with a broader query.' When add rejects a duplicate, return 'Duplicate policy detected. Call get() to review the existing rule, then use supersede() if you want to replace it.'
• Add enum constraints to parameters where applicable. scope could document valid tags; confidence could constrain to [0.0, 1.0]; status in list could be an enum of [active, dormant, superseded, archived]. This prevents hallucinated invalid values.