Skip to main content
Glama
kaelorlabs

Smitline

by kaelorlabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Wait for a call to finish

wait_for_call
Read-only

Wait for an ongoing phone call or meeting to finish and return its outcome, summary, decisions, action items, open questions, and transcript; optionally follow live updates or wake only for requests.

Instructions

Wait for a call to finish and return it with its result: outcome, summary, details such as confirmation numbers, decisions, action items, open questions, and the transcript. If status is not completed, failed, or canceled, call again. Tell the user the outcome in plain words. To follow the call while it happens, pass since: "" the first time, then live.cursor from the last answer. It then also returns as soon as something new is said, with live.transcript holding the new lines (speaker agent is Smitline; other or meeting is the people on the call). Step in with send_call_instruction only when you know something the call needs, or end_call if it goes wrong; otherwise keep waiting. When the brief has canDo, it returns at once when someone on the call asks you for something: live.requests holds it (id, kind question or task, text, askedBy, and the last lines said; source: "speech" when the text is what the person said, passed on because the voice said it would); answer with reply_to_call_request. For a long meeting pass only: "requests" to wake only for requests, without the transcript.

Input Schema

NameRequiredDescriptionDefault
onlyNoWake only for requests from the call, and leave out the transcript. Implies following live.
sinceNoFollow the call live: "" the first time, then live.cursor from the last answer.
callIdYesCall id returned by start_call, such as call-0123456789abcdef
timeoutSecondsNoHow long to wait in this request. Default 50.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.3.0
    • addedInput schema / properties / only
      Added value: +{
+  "description": "Wake only for requests from the call, and leave out the transcript. Implies following live.",
+  "enum": [
+    "requests"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / since
      Added value: +{
+  "description": "Follow the call live: \"\" the first time, then live.cursor from the last answer.",
+  "pattern": "^[0-9]{0,12}$",
+  "type": "string"
+}
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover readOnly/openWorld; the description adds substantive behavior beyond them: the polling contract, the live-following cursor protocol, the wake-on-new-speech semantics, the request-interception behavior when canDo is set, and the meaning of live.transcript speakers. This is rich, non-obvious operational context.

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?

Front-loads purpose and return contents before the live/request modes, so structure is sound. It is dense and contains some internal jargon ('speaker agent is Smitline'), which taxes readability, but nearly every clause conveys operational rules rather than filler.

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?

There is no output schema, so the description carries the burden of describing return values, and it does: outcome, summary, details, transcript, live.cursor, live.transcript, and live.requests fields (id, kind, text, askedBy, source). Combined with polling and escalation guidance, nothing essential is missing.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds protocol-level meaning: 'since: "" the first time, then live.cursor from the last answer' and what only='requests' implies ('wake only for requests, without the transcript', 'Implies following live'). That is genuine value beyond the schema strings, though timeoutSeconds is not discussed.

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?

States a specific verb and resource ('wait for a call to finish and return it with its result') and distinguishes it from get_call/check_call_brief by emphasizing the blocking wait. It also enumerates the return contents, so an agent knows exactly what this tool yields versus siblings.

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?

Explicit when-to-call-again ('if status is not completed, failed, or canceled, call again'), when to switch tools ('send_call_instruction only when you know something the call needs, or end_call if it goes wrong; otherwise keep waiting'), and a special mode for long meetings via only='requests'. Alternatives in the sibling set are named directly.

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

Deploy Server

Other Tools