Rekall defines 4 tools with partial schema coverage. All tools have descriptions (10-120 chars, mostly adequate), but parameter documentation is inconsistent. probe_compaction and compaction_status have minimal descriptions (under 50 chars). Input schemas are present but lack depth: threadId is documented, but handoff object in schedule_compaction has nested properties with descriptions that are present but verbose. No output schemas are documented. Error handling is implicit (validation functions exist but error messages are not surfaced in tool definitions). The server is STDIO-only, which is a hard transport limitation.

• Add output schemas to all 4 tools. Document the structure of probe() response (threadId, connected, ownerId, runtimeStatus, completedCompactions, contextTokens, modelContextWindow, compatibility), schedule() response (jobId, status, createdAt), compaction_status() response (jobId, status, updatedAt), and cancel() response (threadId, jobId, cancellationRequested, message).
• Expand probe_compaction and compaction_status descriptions to 80-150 chars. Explain: 'Retrieve the current status of a compaction job, including job ID, status (not_scheduled|pending|in_progress|completed|resumed|failed|cancelled), and timestamps. Use this to monitor long-running compactions or check if a previous job completed.'
• Document schedule_compaction handoff parameter constraints: 'handoff.summary is required (string, 1-500 chars). handoff.preserve and handoff.discard are optional arrays (max 40 items each). If handoff.resume is true, handoff.nextStep is required (string, 1-200 chars). If resume is false or omitted, nextStep is ignored.'
• Add error recovery guidance to all tool descriptions. E.g., 'If threadId is invalid (not a UUID), the tool returns an error. Pass the current CODEX_THREAD_ID explicitly. If the thread is not connected, probe_compaction returns connected: false, wait for the thread to become idle before scheduling.'
• Document idempotency: 'schedule_compaction is idempotent if called with the same threadId and handoff within a short window (same jobId returned). cancel_compaction is idempotent if the job is already terminal (completed, resumed, failed, cancelled), repeated cancellations return the same status without side effects.'