Which integrations are available for this server?

Captures the live transcript of a Google Meet call and provides AI-generated assistance in a side panel, including summaries, decisions, risk flags, and suggested sentences to say. Captures the live transcript of a Zoom call and provides AI-generated assistance in a side panel, including summaries, decisions, risk flags, and suggested sentences to say.

How do I use meet-live-assist?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@meet-live-assist What was decided about the release date?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

meet-live-assist

by krystiangw

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

Meet Live Assist

Your own agent session, in the call with you. It reads the Meet or Zoom transcript as it happens and answers in a side panel while the call is still going: what was decided, who owns what, the risk you just agreed to, and the sentence to say next, in the meeting's language.

Install from the Chrome Web Store · the site · one command for the server: npx meet-live-assist-server

The store link is one click and updates itself; the repo works loaded unpacked and never does. Either way the server and the skill below are still yours to run, and without an agent attached the advice pane stays empty by design.

During a Google Meet or Zoom call this captures the transcript, shows it in a side panel, and hands it to an assistant running on your own computer. The assistant answers back in the panel while the call is still going: what to say, what was decided, who owns what, what you just agreed to that you should not have.

Transcripts, screenshots and chat are written to a folder on your disk and served by a server on 127.0.0.1 that only you can reach. There is no account, no telemetry, and no server of ours anywhere.

Where the words actually go, stated once and plainly. The brain is your own Claude Code session, so whatever you route to it - the transcript batches, your questions - leaves your machine for Anthropic under your account, exactly as any other Claude Code session does. What never leaves is the stored record: the files, the screenshots, the chat history. If a page tells you a live meeting assistant runs entirely on your machine, it is either using a local model or it is not telling you the truth; this one borrows a brain you already pay for, and that is the trade. See Data flow for the three-line version.

Read this before you install

You need an AI coding agent that speaks MCP - Claude Code is the one this is tested with. This ships the eyes, ears and hands - the capture, the panel, the local bridge - but not the brain. The brain is an agent session on your own machine, reading the call through MCP tools. Without one you get a working transcript recorder and an empty advice pane, which is not what the screenshots promise.

The adapter is plain JSON-RPC over stdio with nothing vendor-specific in it, so other MCP clients (Cursor, Cline, Continue, Zed, Codex) can drive it - Codex CLI was checked and completes tool calls against the bridge. One requirement is genuinely harder to meet elsewhere: the client has to hold a persistent background loop, because MCP is client-pull and nothing on the server can ever start a turn. MCP-CLIENTS.md explains what to check and what is unverified.

Your meeting is other people's conversation too. Turning on captions is invisible to everyone else, unlike recording, which Meet badges. So by default this posts one line into the meeting chat when capture starts, saying an assistant is transcribing locally. You can edit that line or turn it off in Options. Some jurisdictions require everyone's consent before a conversation may be recorded or transcribed; that is your call to make, and PRIVACY.md says so plainly.

Requirements: Node 20+, Chrome 116+, Claude Code. Speaking into the call is macOS-only (it uses say and afplay); elsewhere advice still appears in the panel and the server says why it cannot speak. Local speech-to-text works anywhere ffmpeg and whisper.cpp do, and the panel's setup row names which of the two is missing instead of failing quietly.

Related MCP server: Convo

Install (three steps)

git clone https://github.com/krystiangw/meet-live-assist-extension.git
cd meet-live-assist-extension
./install.sh          # installs the skill, registers the MCP tools, prepares the data dir

Then:

Start the bridge server, leave it running: node server/transcript-server.js --pair
Load the extension: chrome://extensions → Developer mode → Load unpacked → pick this folder. Pin it, click the icon. The panel collects its token from the pairing window on its own; there is nothing to copy. (Window expired? Run step 1's command again - it works against a running server too.)
Open Claude Code and ask it to assist your meeting.

./install.sh takes MLA_USER, MLA_LANGUAGE, MLA_DOMAIN and MLA_TRANSCRIPTS_DIR so the assistant addresses you by name, in your language, and knows roughly what your meetings are about.

Pick a profile

MLA_PROFILE decides which meeting types the assistant knows about and what it leads with. Everything else - the markers, the modes, the board - is the same, because those turned out to be domain-neutral.

Profile	For	It leads with
`engineering` (default)	standups, incidents, refinement, QA	decisions, scope creep, risk, action items
`second-language`	any meeting not in your first language	🟢 SAY - the sentence, ready to speak, in the meeting's language
`research`	user interviews, usability sessions	silence, leading-question warnings, guide coverage
`generic`	anything else	responding well in real time

They are plain files in skill/profiles/ - about a dozen lines each. Write your own and pass its name; the installer refuses a profile it cannot find; it never falls back to the default.

What it stores, and how to get rid of it

Everything lives in one folder - ./transcripts unless you set MLA_TRANSCRIPTS_DIR:

File	What it is
`<date>_<meeting-code>.txt`	the transcript
`<...>.chat.txt`, `<...>.summary.md`	your chat with the assistant, and the post-call summary
`snapshots/<session>/*.jpg`	screenshots taken during screen-share
`.state/`	live meeting state, so restarting the server mid-call loses nothing
`.mla-token`	the shared secret the extension and the assistant authenticate with

Files are owner-only (0600), the directory is 0700, and anything older than 14 days is purged automatically (RETENTION_DAYS, 0 keeps everything forever). The 🗑 button in the panel wipes a single meeting - transcript, chat, summary, snapshots and state - immediately. To remove the whole thing: delete that folder, delete ~/.claude/skills/meet-live-assist, run claude mcp remove meet-live-assist, and remove the extension from Chrome.

Data flow

What	Where it goes
Transcript, screenshots, panel chat, summaries	Your disk, nowhere else. Owner-only files, one folder, served by a process bound to `127.0.0.1`.
The call content you route to the assistant, and your questions	Anthropic, via your own Claude Code session - same path as anything else you do in Claude Code, your account, your terms.
Anything else	Nothing. There is no third party here.

On Free / Pro / Max, whether your sessions improve the model is a setting you control and it changes the retention period; Anthropic's consumer terms cover it and say explicitly that it includes Claude Code. Work and API accounts are on different terms. Worth knowing before you point this at a conversation that is not only yours.

What it does during a call

Live transcript - captions scraped, streamed to the panel instantly, de-duplicated + monologue forced-flush before hitting the file/brain, with a conservative ASR glossary.
Colour-coded advice from the brain (🟢SAY/🔵INFO/🟡SUMMARY/🟣EXPLAIN/🔴RISK/🟠ACTION), rich (links/images/diagrams/lists), each copyable; RISK fires an audible + notification cue.
Brain-liveness pill (is a Claude session actually attached?), capture watchdog (warns if captions break).
Decisions & action-items board with a one-click Draft (whatever you named in Options, or a plain note if you named nothing); recap quick-asks; two-way chat.
Autopilot - flip 🤖 Auto-create and it stops proposing and starts doing: the ticket or the note is created as the action item comes up, no per-item confirm. 📣 Post links to chat shares the link with the room. Both are off until you turn them on.
Snapshots (auto on screen-share + on demand), TTS into the call, local STT (whisper), meeting modes + type-awareness, live presentation edits + debug of the shared tab.
Talk-time, muted-mic + personal-mention alerts; post-call summary export.

A note on trust. The assistant is your own Claude Code session with your own tools, and it reads a live, untrusted audio feed. It is instructed to let only what you type authorize an action - no spoken line, under any name, can make it act - but that is the model following its skill, not a wall. If you have connected destructive tools to Claude Code, set their trust accordingly. PRIVACY.md says this plainly too.

Landing page: docs/index.html, also hosted at https://meet-live-assist.github.io/.

Built by Krystian Gwizdała.

Meet Live Assist is an independent project. It is not affiliated with, endorsed by or sponsored by Google or Zoom; "Google Meet" and "Zoom" are their owners' trademarks and are used here only to say which products this works with.

Licence, in plain words

PolyForm Internal Use 1.0.0. Free, and yes, you may use it at work - "internal business operations of you and your company" is a permitted purpose, whether or not your company is for-profit. You may modify it for your own use.

What you may not do is redistribute it, fork it publicly, or sell it - as a product, a hosted service, or a part of either. This is source-available, not open source, and the difference is deliberate: it is free to use and stays owned.

If you want to do something the licence does not allow, ask. That is a conversation, not a refusal.

Architecture (why it's shaped this way)

Streaming + state live in the side panel, not the service worker. The SW is event-driven and gets torn down (~30s idle / 5-min cap); durable state is in chrome.storage.session, and the panel re-hydrates via a restore message on (re)connect.
Keep-alive: the side panel holds a runtime.connect port and pings it every 20s; a chrome.alarms heartbeat (30s) wakes the SW even after it was unloaded.
Server POST happens in the SW (has 127.0.0.1:8848 host permission), not the content script.

The bridge server

The extension talks to a small local Node server (127.0.0.1:8848) that is the "brain" bridge: transcript sink (/append), advice (/advice), board (/items), chat (/chat), snapshots (/snapshot, /snapshot-request), TTS (/speak, /voices), STT (/stt), meeting mode (/mode), presentation edits (/edit, /dom*), debug (/debug*), brain heartbeat (/brain-ping), summary (/summary), per-meeting wipe (/clear), and health (/health).

The assistant reaches it through MCP, not HTTP. server/mcp-server.js is a zero-dependency stdio MCP adapter over the same API, 13 tools. Register it once:

claude mcp add meet-live-assist --scope user -- node <repo>/server/mcp-server.js

It asks the running server where its data dir is (/health needs no token) and reads the token from there, so it needs no environment. The keystone tool is poll: one call returns the transcript batch worth a turn, the panel's state, and any pending results, with the read offset held server-side per assistant. That replaces four or five curl calls a turn plus a byte offset kept in a shell variable - and it works with no filesystem in reach, which is what a hosted deployment needs.

What MCP does not do is wake the assistant: the protocol is client-pull, so nothing on the server can start a turn. A client-side loop polling /poll?...&format=text remains the wake source; it prints only when something happened - a batch worth a turn, a panel state change, a message typed in the panel chat, a failed meeting-chat delivery, or its own inability to reach the server. The state change matters most: it is the only way pressing Stop can reach an assistant at all, since capture ends there and no later caption would arrive.

Read positions are per reader, held server-side, and a reader nobody has seen before starts at the end of the channel - backlog=1 is how the wake loop asks for the meeting so far on its first read. The loop and the poll tool are deliberately separate readers: reading is destructive, so sharing a position let a mid-turn tool call swallow a wake the loop still owed. Positions are bounded per meeting and evicted least-recently-seen, which never touches a loop that is polling.

Multi-tenancy seam. State is keyed by (user, session); see server/scope.js. On a local install the single user resolves to the data dir itself, so nothing about the layout changes. The seam exists so a hosted profile can namespace users without a second code path, and so the guarantee that one user cannot reach another's meeting is stated in one place and tested directly.

Auth: every route except /health requires an X-MLA-Token header. The server generates the token into <transcripts>/.mla-token on first start; the brain reads that file, and the extension pairs for it, so no human ever handles a copy. Without the token any website you visit could reach the localhost server.

Pairing. GET /pair returns the token exactly once, and only while a window is open - the server's first ever boot, or a run with --pair, which against an already-running server just re-opens the window on it. A claim must carry X-MLA-Pair: 1, which a web page cannot send without a preflight that betrays its origin, and any Origin present must be chrome-extension://. The first claim closes the window and the extension id that took it is logged. This does not stop another extension of yours that already holds a 127.0.0.1 permission from racing you inside those two minutes, which is exactly why the window is not left open. Manual paste still works and is still there in Options.

Two files per meeting. /append writes every caption to <session>.txt - the complete record, nothing dropped - and only appends a batch to <session>.wake when the batch is worth waking the brain for (decisions, blockers, your name, real questions, accumulated substance). The assistant reads the wake channel (through poll), never the raw transcript: that is what keeps a 40-minute call from costing hundreds of brain turns. A held-back batch is never lost - it rides along with the next wake, and a force-flush fires after WAKE_FORCE_MS regardless. poll reads that channel and deliberately does not force it: flushing on a 2-second poll would hand back everything the gate was holding, which is the gate deleted.

Stand up the server

The server stands alone as meet-live-assist-server (zero dependencies), so someone who only wants to run it needs neither this repo nor a clone:

npx meet-live-assist-server

From a clone it is:

node server/transcript-server.js --pair

The extension is on the Chrome Web Store, unlisted: the link installs it in one click and it updates itself, but store search will not surface it, because it is useless to anyone who has not also run the server and attached an agent. Loading the repo unpacked works exactly the same and never auto-updates - run one or the other, not both, since Chrome gives them different extension IDs.

The MCP half is listed in the MCP Server Registry as io.github.krystiangw/meet-live-assist, so a registry-aware client can add it without being told the command. Clients that still want it spelled out: npx -p meet-live-assist-server meet-live-assist-mcp (the package ships two binaries, and npx meet-live-assist-server starts the bridge, not the adapter).

It writes to ~/meet-live-assist/transcripts unless TRANSCRIPTS_DIR says otherwise. Node 20+ is the only hard requirement; ffmpeg and whisper-cli are optional and only local STT depends on them. Binary paths resolve from Homebrew, /usr/local, /usr/bin and then PATH, so Linux works as well as either Mac architecture. Text-to-speech is macOS-only (say + afplay); elsewhere advice still shows as text in the panel and only spoken output is missing. Details: server/README.md.

Publishing a new version is cd server && npm publish. Run npm pack --dry-run first and read the list: it should be eight files, ~61 kB - the server, the MCP adapter, the session-name sanitiser, the state store, the wake-channel cut helper, a README, the licence and the manifest. Anything else in that list is something you did not mean to publish.

Autostart it on a Mac (launchd)

From a clone, if you want it to come back after a reboot:

git clone https://github.com/krystiangw/meet-live-assist-extension.git
cd meet-live-assist-extension
MLA_DRY_RUN=1 ./server/install-server.sh   # optional: see the plan + generated plist, change nothing
./server/install-server.sh                 # install as a launchd agent + start it

It resolves the machine-specific bits itself (node binary via process.execPath - a bare which node under fnm/nvm points at a per-shell shim that dies with the shell; Homebrew prefix for ffmpeg/whisper-cli, so Intel and Apple Silicon both work), writes ~/Library/LaunchAgents/com.mla.meet-transcript-server.plist, waits for /health, then tells you where the token lives. To pair an extension against the job it just installed: node server/transcript-server.js --pair.

Only Node 20+ is required. ffmpeg and whisper-cli are optional (brew install ffmpeg whisper-cpp); without them the server still runs - TTS-into-the-call and local STT are the parts that go dark.
Re-run it after git pull - it is idempotent and restarts the service with the new code.
Override defaults with env vars: TRANSCRIPTS_DIR=~/mla PORT=8849 ./server/install-server.sh. Default transcripts dir is ~/meet-live-assist/transcripts, deliberately outside the repo - meeting text and screenshots are PII and must not risk being committed.
The brain reaches the server through the MCP adapter, which asks it where its data is, so changing TRANSCRIPTS_DIR needs no change on the assistant's side. Only the launchd plist and the extension's token need to agree.

Manual run instead of launchd (handy for debugging - logs to your terminal, Ctrl-C stops it for real):

PORT=8899 TRANSCRIPTS_DIR=/tmp/mla node server/transcript-server.js
curl -s http://127.0.0.1:8899/health

Operating it


health	`curl -s http://127.0.0.1:8848/health`
what the panel is asking of the brain	`curl -s -H "X-MLA-Token: $(cat <transcripts>/.mla-token)" "http://127.0.0.1:8848/status?session=<session>"`
logs	`~/Library/Logs/meet-live-assist-server.log`
restart	`launchctl kickstart -k gui/$UID/com.mla.meet-transcript-server`
stop for real	`launchctl unload -w ~/Library/LaunchAgents/com.mla.meet-transcript-server.plist`

KeepAlive is on, so kill/pkill does not stop it - launchd restarts it within seconds.

A restart mid-call is survivable. Advice, the decisions board, chat, the wrap-up, the wake buffer and each assistant's read position are snapshotted to <transcripts>/.state/ and reloaded on boot, so a bounce costs at most the last couple of seconds (STATE_SNAPSHOT_MS, default 2000), never the meeting. Two things deliberately do not come back, because they are answers about one call and a recurring series reuses its meet code: the panel's Stop/pause state, and consent (🕹 drive, autopilot). You will still see a brief capture gap while the process is down.

Only one process may write a given data dir. A second server on the same TRANSCRIPTS_DIR serves normally but does not persist (it logs why), so a sandbox run beside the launchd job cannot rewind the live meeting.

Config (all optional, set in the plist's EnvironmentVariables or on the manual command line):

var	default	what it does
`PORT`	`8848`	the extension has host permission for `127.0.0.1:8848` - changing it needs a manifest change
`TRANSCRIPTS_DIR`	`<server-dir>/../transcripts`	where transcripts, snapshots and `.mla-token` live
`RETENTION_DAYS`	`14`	purge transcripts + snapshots older than this (`0` = keep forever)
`WAKE_BASE_MS` / `WAKE_MAX_MS`	`10000` / `90000`	wake-gate backoff window: starts here, doubles on an empty batch up to the max
`WAKE_FORCE_MS`	`180000`	flush whatever is buffered after this long, gate or no gate
`WAKE_MAX_CHARS`	`4000`	flush early once a batch gets this big
`WAKE_MIN_GAP_MS`	`8000`	floor between two wakes
`MLA_URGENT_NAMES`	(empty)	comma-separated names that wake the assistant immediately - include the manglings your captions produce
`WAKE_ALL`	`0`	`1` delivers every line with no gating, for a call where nothing is small talk (~4x the turns)
`FFMPEG` / `WHISPER_CLI` / `WHISPER_MODEL` / `TTS_VOICE`	Homebrew paths / `Zosia`	TTS + STT plumbing

The launchd plist is generated by install-server.sh from your machine's actual paths - there is no template to edit, because a checked-in one would carry someone else's absolute paths and fail on yours.

Two builds, and the skill that matches each

./build.sh zips everything this repo can do. ./build.sh --public produces the store zip: it drops the debugger permission and strips the surface that acts on pages (DOM edits, agent-driven clicks, network/console reads), leaving the assistant that only sees and hears. The store reviews for a single purpose, and the full build reads as a remote control. The cut is driven by mla:pro-start / mla:pro-end markers in src/; the build refuses to ship a dangling reference to anything it removed.

The bundled skill is cut the same way and, more importantly, is a template - it addresses the user by name, answers in their language and pre-briefs against their domain, none of which can be hardcoded for someone else. install.sh fills it:

MLA_USER="Ada Lovelace" MLA_LANGUAGE=Polish MLA_DOMAIN="backend eng, payments" ./install.sh
MLA_PRO=1 ./install.sh      # keep the page-control sections (pairs with the full build)

It refuses to run on the author's machine without MLA_FORCE=1, because there the destination is the canonical personal skill, not a copy of the template.

Checks

npm run lint            # node --check over src/ and server/
npm test                # all five suites below, ~296 checks
npm run test:scope      # the (user, session) rules in isolation
npm run test:server     # auth gate, session guard, round-trips, restart survival
npm run test:panel      # every request sidepanel.js makes, replayed without a browser
npm run test:mcp        # the MCP adapter over stdio JSON-RPC
npm run test:limits     # the size caps, with non-ASCII text
npm run test:retention  # the retention sweep, and content not leaking between meetings

Both run in CI on every push, along with both builds.

The suites are split by what they protect, not by layer. test:panel exists because the panel is the half of the product a server test never touches - a renamed route or a cursor that stops advancing looks fine from the assistant's side and leaves the user staring at an empty panel. test:limits is the only suite that uses non-ASCII text, and three real defects were hiding behind English-only fixtures. test:retention needs file timestamps and restarts with a gap, so it does not belong in the fast path.

Load it (unpacked)

Make sure the transcript server is running - curl -s http://127.0.0.1:8848/health → {"ok":true,...}. On a fresh Mac install it first: ./server/install-server.sh (see Stand up the server on a Mac above).
chrome://extensions → enable Developer mode → Load unpacked → pick this folder.
Pin the extension; click its toolbar icon to open the side panel.
The panel pairs itself with the server if a pairing window is open (--pair). If it is not, the pill says so and you can still paste the token by hand: right-click the icon → Options → cat <TRANSCRIPTS_DIR>/.mla-token. The token is per-machine; one from another Mac will be rejected. Optionally set TTS voices and your name(s) (for mention alerts). The panel's ⚙ shows a setup checklist.
If you ever ran the predecessor Tampermonkey userscript (server/legacy-userscript.meet-captions-to-file.user.js), disable it - both capturing at once duplicates every line.

Does it actually work? Check these on a real call

Automated tests cover the server; these cover the half that only a live meeting exercises.

Join a call → within a few seconds the panel shows capturing and live lines, and <TRANSCRIPTS_DIR>/<date>_<code>.txt starts growing.
server ✓ is green and the 🧠 pill names your attached assistant. A pill that says nobody is attached while a session is running means the skill never armed - that is the failure mode worth catching, because everything else looks fine while no advice will ever arrive.
Ask the assistant something in the panel chat and get an answer back in the panel.
Service-worker death: let the SW go idle (or Stop it in chrome://serviceworker-internals) and keep talking. Capture resumes and the panel re-hydrates without a reload. A 10-minute call should have no gaps.
Share your screen → snapshots start on their own; the 📷 pill shows how stale the assistant's view is.
Leave the call → the panel shows call ended.

How the halves talk. The brain POSTs advice (POST /advice {session, marker, text}) and the panel polls GET /advice?session=&since=, rendering each with its colour marker. Snapshots go to <TRANSCRIPTS_DIR>/snapshots/<session>/ (~40 kept) for the assistant to read on demand. Anything the assistant does outside the panel - a ticket, a message - follows the tiers in the skill, and the panel itself is display-only.

Permissions

The <all_urls> host is optional, requested at runtime on a user gesture (starting co-pilot, turning on 🐞 Debug, or the setup checklist's Grant button), so the host prompt stays limited to Meet + Zoom + localhost. debugger stays a required permission - Chrome forbids listing it as optional - so it's in the install prompt (heavier review; a public build can drop it, the code degrades gracefully). Token auth closes the "any website can drive the localhost server" hole. Build the store zip with ./build.sh (→ dist/, extension files only). Full listing + justifications: STORE.md.

Reloading an already-installed copy will drop the now-optional <all_urls> grant - re-grant once from the panel (co-pilot / 🐞 / ⚙ setup → Grant).

Roadmap

Mute-aware mic capture (deferred 2026-07-28 - idea worth keeping). Muting yourself in Zoom does not stop the OS microphone, so the mic STT channel keeps recording asides nobody in the call heard, and the brain treats them as things you said in the meeting. Don't drop them - label them You (muted): so muting becomes a deliberate private voice channel to the assistant (still authorizes actions; never quotable as something said to the room). Open question is only how to read the state: the toolbar button is localized ("Wyłącz wyciszenie" / "Unmute"), so it needs a state attribute or an icon class, not a text match - the same fragility that already bit the caption selectors.
Auth north-star (product): user authorizes a provider (Claude, later ChatGPT) in the extension's settings and it "just works." Reality: the Agent SDK / API is API-key based, not account-OAuth, and a pure extension can't run the MCP agent brain (needs Node). So the full-brain path needs a local bridge or a hosted backend; the pure-extension path is BYO-key (weaker, no MCP). Revisit in Phase 3.
Phase 2: replace caption scraping with chrome.tabCapture audio → streaming STT; auto-detect "key moments" for snapshots; in-panel chat.
Phase 3 (optional): Agent SDK brain (@anthropic-ai/claude-agent-sdk, settingSources:["user"] to inherit CLAUDE.md + MCP) via local bridge, or backend proxy / BYO-key (Path B) for sharing; privacy policy; Workspace private store.

Available Tools

13 tools

adviceB

Show a line in the side panel. SAY = words to say now, RISK = a problem, INFO = context, EXPLAIN = a term, ACTION = do this, SUMMARY = recap. Keep it one glanceable sentence.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes
`marker`	No
`session`	No

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the content format and marker meanings but does not disclose side effects, return behavior, session semantics, or any limitations of the side-panel display, leaving significant behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core action, and highly efficient. It packs marker definitions into a compact, readable list without any wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple display tool with no output schema or annotations, the description covers the primary behavior and content semantics well. However, the unexplained `session` parameter and lack of details about side-panel interaction (e.g., persistence, replacement) leave gaps that an agent would need for fully correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning to the `marker` parameter by defining each enum value and provides guidance for `text` (keep it one glanceable sentence). However, the `session` parameter is completely undocumented, and with 0% schema description coverage, the description only partially compensates for the missing parameter explanations.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action and target ('Show a line in the side panel') and enumerates the marker categories, which clarifies its purpose. It does not explicitly distinguish from sibling tools, but the side-panel UI and marker semantics make it distinctive enough.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied through the marker definitions (e.g., use RISK for a problem, ACTION for a to-do), but the description does not explicitly say when to use this tool over siblings like `chat_reply` or `speak`, nor does it provide exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

attachA

Pin the meeting to assist and report its state. Call once at the start. Refuses if another assistant is already live on it unless force is set.

ParametersJSON Schema

Name	Required	Description	Default
`force`	No	Attach even if another assistant is live.
`session`	No	Meeting id. Omit to take the most recently active one.

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses the refusal behavior and the force condition, which is valuable. However, it doesn't explain what 'report its state' means, any permissions needed, or consequences of force beyond attaching.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the main action, then usage instruction, then a caveat. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 2-parameter tool with no output schema, the description covers purpose, timing, and a key edge case. It could clarify what 'report its state' entails, but overall it's sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description mentions 'force' in context of refusal, but the schema already describes force as 'Attach even if another assistant is live,' so no significant added meaning. Session is not discussed in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action ('Pin the meeting to assist and report its state') with a specific verb and resource, making its purpose obvious. It doesn't explicitly differentiate from sibling tools, but the action of attaching/initializing a session is distinct from the listed siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says 'Call once at the start,' providing a clear when-to-use instruction. It also describes the refusal condition and force bypass, but doesn't mention alternatives or when-not-to-use scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

call_chatA

Send a message into the meeting chat, visible to everyone. Returns the delivery result; poll reports failures too.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes
`session`	No

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It discloses return behavior ('Returns the delivery result') and indicates failures are reported via polling ('poll reports failures too'). It does not mention safety, permissions, or rate limits, but for a simple send operation this is acceptable partial disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long and front-loaded with the primary purpose. The second sentence adds valuable behavioral details about the return value and failure reporting. No words are wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is relatively simple, but the description leaves gaps: it does not clarify what 'session' refers to, what the 'delivery result' looks like, or how polling for failures works. Given no output schema and no annotations, a bit more detail would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema lists two parameters (text and session) with no descriptions (0% coverage). The description clarifies that 'text' is the message content ('Send a message'), but it does not explain the 'session' parameter at all, leaving users to infer its meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Send a message into the meeting chat, visible to everyone.' It uses a specific verb (send) and resource (meeting chat) and distinguishes from siblings like chat_reply by emphasizing visibility to everyone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'visible to everyone' implies the tool is for public messages, which provides some usage context. However, it does not explicitly state when to use it versus alternatives like chat_reply, nor does it mention any exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

chat_replyA

Reply in the side panel chat, where the user types to you privately. Not the meeting chat - that is call_chat.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes
`session`	No

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of behavioral disclosure. It adds useful context about the private side panel vs. meeting chat, but does not explain side effects, return values, permissions, or the session parameter. This is minimal but not misleading.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the main action (reply in side panel chat) and immediately clarifies the common confusion (not meeting chat). Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, but the description lacks explanation of parameters and return behavior. Given no annotations and no output schema, the description is sufficient for purpose but incomplete for full invocation confidence.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% documentation coverage, and the description does not explain the 'text' or 'session' parameters at all. The description adds no semantic value beyond the raw schema, leaving the agent uninformed about parameter purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: replying in the side panel chat. It explicitly distinguishes this from the meeting chat by naming call_chat as the alternative, making it easy to understand the tool's specific role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides an explicit when-not-to-use and names the alternative tool (call_chat) for the meeting chat. However, it does not mention other sibling tools like speak or attach, so guidance is incomplete but adequate for the primary alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

itemB

Add to the decisions and action-items board. Only for things actually decided or assigned, not for topics discussed.

ParametersJSON Schema

Name	Required	Description	Default
`kind`	No
`text`	Yes
`owner`	No
`session`	No
`blocked_by`	No

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It does not disclose side effects, permissions, or persistence behavior beyond the implied 'add' action. It also doesn't describe what happens to existing items or whether duplicates are allowed, which is a significant gap for a mutating tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is highly concise, consisting of a single sentence with two clauses. It front-loads the core action ('Add to the decisions and action-items board') and immediately follows with a key constraint. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has five parameters and no output schema, yet the description offers no context on parameter usage, expected outcomes, or integration with sibling tools. It barely covers the basic purpose, leaving the agent to infer field semantics and any board-specific behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain any of the five parameters (kind, text, owner, session, blocked_by). There is no compensation for the low schema coverage, so the agent has no semantic guidance beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Add to the decisions and action-items board.' It also distinguishes scope by specifying 'Only for things actually decided or assigned, not for topics discussed.' This is a specific verb+resource and provides a clear boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when not to use it ('not for topics discussed'), providing a clear exclusion criterion. However, it does not name alternative tools, so it falls short of fully explicit alternatives, but the when-not guidance is strong.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pollB

Everything new since your last poll: transcript batch worth a turn, panel state (paused/mode/autopilot/suppressed topics), and any pending results. One call per turn; the offset is tracked server-side.

ParametersJSON Schema

Name	Required	Description	Default
`session`	No

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations are provided, the description carries the full burden. It discloses the key behavior of returning only new data and tracking offset server-side, which implies a non-idempotent, stateful operation. However, it does not mention side effects like consuming the updates or what happens if there is no new data. The transparency is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose ('Everything new since your last poll'). It includes a concise list of return contents and a critical behavioral constraint. Every sentence earns its place with no waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema or annotations, so the description must explain the return format and usage context. It lists the three types of returned data (transcript batch, panel state, pending results) and notes the single-call-per-turn constraint. However, it leaves the 'session' parameter unexplained and does not clarify what to do with the returned data or how errors/empty states are handled. For a polling tool, this is a notable gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has one optional parameter 'session' with no description and 0% schema description coverage. The tool description completely ignores this parameter, offering no explanation of what 'session' represents or how it affects the call. The description adds zero semantic value beyond the raw schema, failing to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns new updates since the last poll, listing specific content (transcript batch, panel state, pending results). It distinguishes itself from siblings by focusing on delta updates, though it does not explicitly name alternatives. The purpose is clear enough for an agent to understand what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides usage guidance: 'One call per turn' and the note about server-side offset tracking imply a polling pattern. However, it lacks explicit exclusions or comparisons to sibling tools (e.g., 'use transcript instead for full history'). There is no clear 'when not to use' guidance, so the score is below a 4.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

snapshot_readC

List captured screen snapshots for this meeting, newest first, with their paths.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`session`	No

TDQS

C2.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must expose behavioral traits. It reveals ordering and return content (paths) but does not state that the operation is read-only, mention any side effects, authentication needs, or error behaviors. The read-only nature is implied but not explicitly disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the key action and result details without waste. Every word contributes value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the tool is simple with only optional parameters and no output schema, the lack of parameter explanations and absence of any behavioral caveats makes the description incomplete for safe and correct invocation. An agent would need to guess the semantics of 'limit' and 'session'.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the two parameters (limit, session), and the description does not explain their meaning or format. The agent cannot infer what values to provide or how they affect results, leaving a significant gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists captured screen snapshots for the meeting, with ordering (newest first) and content (paths). It implicitly distinguishes from sibling tool snapshot_request by focusing on reading existing snapshots rather than requesting new ones, but does not explicitly name the alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives like snapshot_request. The phrase 'for this meeting' implies meeting context but lacks explicit when-to-use or when-not-to-use instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

snapshot_requestA

Ask the extension to capture the shared screen. Returns immediately; read the image with snapshot_read on a later turn.

ParametersJSON Schema

Name	Required	Description	Default
`session`	No

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of behavioral disclosure. It reveals a key behavioral trait: 'Returns immediately,' indicating an asynchronous operation. It also implies the image is not immediately available, which is important context. However, it does not mention potential failure modes, session-specific behavior, or what the immediate return value signifies.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that delivers all necessary information without fluff. Every phrase contributes: the action, the immediate return behavior, and the follow-up step. It is concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one optional parameter, no output schema), the description covers the core workflow of capture-then-read. However, it lacks any explanation of the 'session' parameter and does not describe the immediate return value or success/failure signaling. The missing parameter semantics and return info leave gaps for an agent to make correct calls.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has one parameter 'session' with zero description coverage. The description does not mention this parameter at all, providing no semantic meaning beyond the type 'string.' An agent has no way to infer what 'session' should contain or how it affects the capture, making this a significant gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action: 'capture the shared screen.' It distinguishes itself from the sibling tool snapshot_read by explicitly noting the image must be read later via snapshot_read, making the purpose and relationship unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidance by stating 'read the image with snapshot_read on a later turn.' This tells the agent exactly when to use this tool (to request capture) and when to use the alternative (to retrieve the image), fulfilling the need for when-to-use vs alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

speakA

Say something out loud into the call. Local macOS installs only; fails with an explanation elsewhere.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes
`voice`	No
`device`	No
`session`	No

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses the platform limitation and failure mode ('fails with an explanation elsewhere'), which is valuable. However, it does not explain the effect on the call (e.g., whether it interrupts, requires an active call, or is asynchronous), leaving behavioral uncertainty.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the action, no filler words. Perfectly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 parameters, no annotations, and no output schema, the description is too sparse to be fully complete. It omits parameter meanings and deeper behavioral context, making it adequate only for a very simple use case.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage and the description provides no elaboration on parameters like voice, device, or session. It only implies that 'text' is the content to speak. The description does not compensate for the schema's lack of documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with a specific verb ('Say') and resource ('something out loud into the call'), and the phrase 'out loud' differentiates it from text-based chat tools like chat_reply. It also adds a platform constraint. The only slight weakness is that 'something' is generic, but the intent is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear context (speaking aloud into a call) and an explicit when-not constraint (only local macOS installs, fails elsewhere). However, it does not name alternative tools or provide explicit comparison criteria, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

summaryC

Save the post-call wrap-up as markdown. The panel offers it for copy and download.

ParametersJSON Schema

Name	Required	Description	Default
`session`	No
`markdown`	Yes

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It mentions saving and a panel offering copy/download, but does not explain persistence, permissions, reversibility, or response behavior. 'Save' implies mutation but lacks important details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded with the primary action. The second sentence about the panel adds useful context, though it is somewhat vague. Overall, it is concise without excessive fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a mutation tool with no annotations, no output schema, and incomplete parameter explanations. The description provides the core purpose but leaves significant gaps about usage, parameters, and side effects, making it incomplete for reliable tool invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It explains that 'markdown' is the content format, but the 'session' parameter is completely unaddressed. The description adds minimal meaning beyond the parameter names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool saves the post-call wrap-up as markdown, specifying the verb 'save' and the resource ('post-call wrap-up') and format ('markdown'). However, it does not explicitly distinguish this from related sibling tools like 'transcript' or 'working'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'post-call wrap-up' implies this tool is used after a call, giving some usage context. However, there is no explicit guidance on when to choose this over alternatives or any exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

transcriptA

Read the complete meeting record, not just the batches worth a turn. Use for wrap-up or to reconcile something you missed.

ParametersJSON Schema

Name	Required	Description	Default
`session`	No
`tail_lines`	No	Last N lines (default 200, max 2000).

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It adds the key behavioral trait that it returns the complete record, not just a recent slice. However, it does not disclose potential limitations like output format, rate limits, or how tail_lines interacts with the 'complete' claim. The disclosure is minimal but non-contradictory.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose, and every phrase earns its place. It succinctly conveys scope and usage without wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, but the description leaves gaps: the session parameter is undocumented, and the relationship between 'complete record' and the tail_lines parameter (which limits to last N lines) is ambiguous. The phrase 'complete meeting record' might mislead an agent into thinking it always returns everything, while tail_lines suggests a limit. Given no output schema and no annotations, the description should clarify these points.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 50% (tail_lines is described, session is not). The description does not compensate: it never mentions session or tail_lines, leaving the required session parameter unexplained. The meaning of tail_lines as 'last N lines' is provided by the schema, but the description adds no additional semantic value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reads the complete meeting record, distinguishing it from other tools that provide only partial batches. The verb 'Read' and the resource 'meeting record' are specific, and the contrast with 'batches worth a turn' differentiates it from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use: 'Use for wrap-up or to reconcile something you missed.' This gives clear usage context. While it does not explicitly name alternative tools, the phrase 'not just the batches worth a turn' implies when not to use it (when only recent context is needed).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

wake_modeA

Switch how much of the meeting reaches you. 'all' delivers every line with no gating - use it when the user says the call is dense and they want nothing filtered (an interview, a negotiation). 'gated' is the default and holds back small talk. The transcript file always has everything either way; this only changes what wakes you, and 'all' costs roughly four times the turns.

ParametersJSON Schema

Name	Required	Description	Default
`mode`	Yes
`session`	No

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description fully bears the burden. It discloses that gated filters small talk, that the transcript always retains everything, and that 'all' consumes roughly four times the turns—critical behavioral implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Efficient, front-loaded statement with no filler; each sentence adds distinct value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter tool with no output schema, the description provides sufficient context for invocation: semantics of both modes, default behavior, cost, and relationship to transcript. No further detail is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description richly explains the 'mode' enum values ('all' with no gating, 'gated' as default with small talk held back), but does not mention the optional 'session' parameter. Since schema coverage is 0%, the description compensates for the key parameter but leaves session unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the verb 'Switch' with a clear object ('how much of the meeting reaches you') and explains the two modes ('all' and 'gated') with their intended use cases, distinguishing it from sibling tools like chat_reply or speak.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use 'all' (dense calls like interviews/negotiations) and that 'gated' is the default for holding back small talk; also notes the cost difference, giving clear selection criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

workingA

Heartbeat, so the panel shows you are alive. Pass status to show what you are doing ("checking Jira"); pass an empty status when done. Call every turn.

ParametersJSON Schema

Name	Required	Description	Default
`status`	No
`session`	No

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral disclosure burden. It explains the heartbeat behavior and how to use status, but does not mention the session parameter or any potential side effects, leaving some gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short, purposeful sentences with no repetition or fluff. The information is front-loaded and every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, and the description covers the heartbeat purpose and usage, but the unexplained 'session' parameter and absence of any mention of return values or additional context make it only partially complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides no descriptions for the two parameters (0% coverage). The description explains the 'status' param (e.g., 'checking Jira', empty when done), but completely omits the 'session' param, failing to compensate for the low schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as a heartbeat mechanism ('so the panel shows you are alive') and its specific action of passing status. This is a specific verb+resource that distinguishes it from siblings like chat_reply or snapshot_read.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit usage instructions: pass a status to indicate activity, pass an empty status when done, and call every turn. While it gives clear context and the 'when', it lacks explicit when-not-to-use or alternative recommendations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

13 tool updatesv1.0.0Aug 17, 2026
- First observedadvice
- First observedattach
- First observedcall_chat
- First observedchat_reply
- First observeditem
- First observedpoll
- First observedsnapshot_read
- First observedsnapshot_request
- First observedspeak
- First observedsummary
- First observedtranscript
- First observedwake_mode
- First observedworking

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored 2026-08-17 09:20 across 13 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: private vs public chat, audio vs text, snapshot request vs read, incremental poll vs full transcript. Descriptions explicitly disambiguate similar functions (e.g., chat_reply is noted as not call_chat).

Naming Consistency2/5

Tool names are highly inconsistent: some are verb-first (chat_reply, wake_mode), some noun-first (snapshot_read, snapshot_request), some single verbs (speak, attach, poll), and some bare nouns (summary, transcript, advice, item). No predictable pattern emerges.

Tool Count5/5

13 tools is appropriate for a live meeting assistant, covering communication, state control, transcript access, snapshots, and action items. Each tool earns its place without redundancy or bloat.

Completeness4/5

The tool set covers the core workflow: attach to a meeting, monitor via poll/transcript, communicate through multiple channels, capture screenshots, and wrap up with summary/items. Minor gaps like explicit session teardown or finer-grained state control exist but are workable.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

meeting-agents A
ai.mainroom
AI agents that join live Google Meet, Teams, and Zoom calls as speaking participants.
Communication Autonomous Agents
61
Vexa
ai.vexa
Meeting bot and transcripts for Google Meet, Teams and Zoom. Live or after, speakers labelled.
Speech Processing Workplace & Productivity
12,762
MyGhostsOAuth
app.myghosts
Send AI bots to attend meetings on your behalf. Get recordings, transcripts, and summaries.
Communication Autonomous Agents App Automation
2
Speak AIOAuth
io.github.speakai
Search recordings, summarize meetings, create clips, and automate workflows from your AI assistant.
Speech Processing AI & Machine Learning Multimedia Processing
2

Related MCP Servers

ChatterBox MCP Server
Communication Text Summarization
ChatterBoxIO
A
license
B
quality
D
maintenance
A Model Context Protocol server that enables AI agents to join and interact with online meetings (Zoom and Google Meet), capturing transcripts and recordings to generate meeting summaries.
Updated a year ago (2025-07-15 19:52 UTC)
3
10
MIT
Convo
Communication Workplace & Productivity Project Management
itsconvo
A
license
A
quality
D
maintenance
Access your meetings, transcripts, summaries, and action items from Convo, an AI meeting assistant. Cross-meeting intelligence: prepare for calls with past context, get weekly digests, and track action items across all meetings. Works before, during, and after your meetings.
Updated 5 months ago (2026-04-20 10:49 UTC)
12
36 npm
1
MIT
Meetings MCP Server
Calendar Management Workplace & Productivity Search
ethereumfollowprotocol
A
license
Not graded
quality
F
maintenance
Provides read-only access to Google Drive meeting transcripts and Google Calendar events, enabling AI assistants to search, analyze, and retrieve meeting insights.
Updated a year ago (2025-09-12 03:17 UTC)
22 npm
3
MIT
Docket MCP Server
Project Management Workplace & Productivity
het2576
F
license
D
quality
C
maintenance
Enables extracting action items from meeting transcripts and managing them in Notion, with duplicate detection and human review.
Updated 2 months ago (2026-07-02 20:25 UTC)
3
-