memory-pulse defines 4 tools with complete input schemas and descriptions. Naming is clear and verb-driven (remember, pulse, recall, execute). Descriptions are adequate (60-180 chars) but lack LLM-optimized guidance on WHEN to use each tool vs alternatives. Parameters are well-typed with enums where appropriate (kind, tier, scope). However, output schemas are not documented, LLMs cannot predict what pulse() or recall() return, forcing blind invocation. Error handling is minimal; no recovery guidance. Security is strong (no secrets in params, offline-first design). Composition is sound: each tool has one responsibility, and tools chain naturally (recall → execute → remember). Baseline: 549 production tools average 194-char descriptions and 100% document return types; memory-pulse lacks both.

• Document output schemas for pulse, recall, execute. Example: 'pulse returns {brief: string, corrections: [{cause, effect, tags}], loaded_line: string}'. This enables LLMs to extract and chain results.
• Expand tool descriptions to 150-250 chars with explicit WHEN guidance. E.g., 'pulse: Send ledger to hosted engine for AI-powered corrections summary. Use when you need a high-level brief; use recall() for targeted queries. Returns corrections-first summary and forgets request for privacy.'
• Add error recovery hints to pulse description: 'If rate-limited, retry with a valid key. If network fails, fall back to recall() for local queries.'
• Document recall() result limit and filtering: 'Returns up to 100 matching events from the ledger. Use pattern to narrow results (e.g., pattern='bug' returns events with 'bug' in cause or effect).'
• Add parameter constraints to pulse.tier: 'brief: summary only (~50 tokens); full: detailed analysis with all corrections (~200 tokens). Choose brief for quick checks, full for comprehensive review.'