meet-live-assist
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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. |
| 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. |
| transcriptA | Read the complete meeting record, not just the batches worth a turn. Use for wrap-up or to reconcile something you missed. |
| 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. |
| itemB | Add to the decisions and action-items board. Only for things actually decided or assigned, not for topics discussed. |
| chat_replyA | Reply in the side panel chat, where the user types to you privately. Not the meeting chat - that is call_chat. |
| 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. |
| 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. |
| summaryC | Save the post-call wrap-up as markdown. The panel offers it for copy and download. |
| snapshot_requestA | Ask the extension to capture the shared screen. Returns immediately; read the image with snapshot_read on a later turn. |
| snapshot_readC | List captured screen snapshots for this meeting, newest first, with their paths. |
| call_chatA | Send a message into the meeting chat, visible to everyone. Returns the delivery result; poll reports failures too. |
| speakA | Say something out loud into the call. Local macOS installs only; fails with an explanation elsewhere. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
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).
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.
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.
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.