Meeting preparation

Preparing well starts with knowing what is coming. Meeting preparation brings the next meetings into a time-ordered report, with links back to the calendar records your team already uses.

Try the report

Enable Meeting preparation in Plugins, then choose Run report. The workspace must contain readable calendar events; the report itself has no additional connection settings. The plugin starts disabled. Use an authorized workspace, or explore Plugins in the fictional demo.

A fictional confirmed discovery meeting starts in an hour, while another appointment was cancelled. Run the report to see the confirmed meeting and open its source record to plan your preparation.

Non-cancelled meetings starting now through, but not including, 48 hours ahead are sorted by start time. This version identifies meetings; it does not research attendees or generate a briefing.

Reading the result

Treat each finding as a reason to open its source record, not as a verdict on its own. Check the inspected-record count and any truncation notice before drawing a conclusion from what's shown: each source caps at 100 records, the combined input at 64 KiB, and displayed findings at 20, so an empty result means nothing matched in that particular snapshot, not that your whole business is clear.

The report itself is read-only and deterministic: it never changes a business record and never contacts anyone. Its AI/MCP tool is run_meeting_prep, and the host checks whether the plugin is actually enabled every time it runs. Running it needs no write approval and makes no model request on its own, though hosting and database usage still apply, and an AI conversation you have around the report can still incur its own model charges.

What this example teaches you to build

Use time-windowed records as the foundation for a preparation workflow. A richer briefing would need additional sources and a separately implemented step. Keeping those layers explicit makes the small report useful on its own.

Start with the report source and its module manifest. The report code receives declared fields inside the shared isolate; the host supplies access and records the result. Reuse that boundary when changing the logic.

What to check, and how to turn it off

Turning the plugin off in Plugins stops new evaluations immediately; source records and historical receipts stay exactly as they were. For a missing-source or access error, check the workspace's source registration and permissions, correct them, and rerun, and for a truncated result, go inspect the source records directly rather than assuming whatever got cut off would have been clear. Running the report again never creates a duplicate task or message, so re-running it to double-check is always safe.

The developer guide links the source contracts and controlled tests, including npm run test:report-plugins. Those fixtures exercise the report behavior; they do not verify every installation's data or provider connections.