Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

A part per service

A part is eddy’s code for one meeting service, run as an adapter. Its own code does two things: it lists the meetings its service recorded since its cursor, and it fetches each meeting’s transcript. Everything else a part does, every other part does the same way, and the next chapter describes it.

What a part owns and what it shares Three parts, wispr for Wispr Flow's MCP endpoint, webex for Webex's transcripts API and teams for Microsoft Graph's meeting transcripts, each own only listing and fetching. Below them, one layer every part shares: the key's shape, the meeting's title, start, length and attendees, the raw layout, and skipping a meeting too short to hold anything. Below that, flywheel-next's capture crate holds the contract's types and key rules. OWN CODE, ONE PART PER SERVICE wispr Wispr Flow's MCP endpoint list fetch webex Webex's transcripts API list fetch teams Microsoft Graph's transcripts list fetch Shared by every part, in eddy the key's shape · title, start, length, attendees · the raw layout · skipping a meeting too short to hold anything flywheel-next's capture crate the contract's types and key rules, JSON in flight, used by millpond, Flywheel, headwater and eddy
A part's own code is listing and fetching from its service. What every meeting part shares is written once in eddy, and the contract's types and key rules once in flywheel-next's capture crate. Adding a service adds one box to the top row.

The parts

PartSourceKeyWhen
wisprWispr Flow’s MCP endpoint, over HTTPmeeting/wispr/<meeting id>first
webexWebex’s transcripts APImeeting/webex/<meeting id>when a partition records on Webex
teamsMicrosoft Graph’s meeting transcriptsmeeting/teams/<meeting id>when a tenant’s administrator consents

wispr comes first. Wispr Flow serves its meetings through an MCP endpoint over HTTP. The part is an MCP client of that endpoint, with a sign-in of its own, and calls the endpoint’s tools from its own code. No Claude session runs to list meetings, since a listing is arithmetic and runs unattended (115).

webex reads Webex’s transcripts API. eddy gains it when a partition records its meetings on Webex.

teams reads Microsoft Graph’s meeting transcripts. Graph serves a tenant’s transcripts only to an application the tenant’s administrator has consented to, so the part comes when an administrator consents.

Its sign-in

A part that signs in to its service keeps that sign-in itself. The host’s only job is to hand the part what the plugin declared:

  • On millpond the user signs in once per host, and the part keeps the sign-in from then on.
  • On Flywheel the host places the secrets the plugin declares (228).

Either host starts the part with each declared secret in its environment, under the secret’s declared name. A fleet’s user makes a part’s sign-in once per host, beside the other sign-ins that host holds.

Its cursor

A part lists the meetings its service recorded since its cursor. The cursor is the part’s own, and millpond treats it as opaque: millpond keeps the last cursor from a run that ended in its done line and hands it back on the next run. A part works with no cursor at all. Listing a window again is safe, because millpond dedupes by key, so a lost cursor costs one wider listing and no second capture (111).

Its tests

eddy tests each of its parts by replaying the service’s recorded responses, so a part’s tests need no account, no sign-in and no network. A part counts as a meeting part when it also passes the meeting checks in the conformance pack, which How others add a service describes.