Smitline

Overview Schema Source Related Servers Discussions Admin

Check a call brief

check_call_brief

Read-only

Checks a call or meeting brief without dialing or joining, returning readiness, blocking problems, and prior-note counts so you can confirm completeness before starting.

Instructions

Validate a brief exactly as start_call would, without placing a phone call or joining a meeting. Returns ok, the brief as it would be placed, the problems that would stop it (such as missing setup or a refused number), and how many earlier calls' notes it would start with. Missing fields come back as brief_incomplete with a question to ask the user. Use it when unsure whether a brief is complete; start_call runs the same checks itself.

Input Schema

Name	Required	Description
`to`	No	E.164 phone number such as +14155550142, or the meeting invite URL. Omit only for a rehearsal, which rings the user's own phone.
`task`	No	The job several calls serve, such as getting quotes from ten roofers. Use the same id for each call in it.
`tone`	No	How to come across, such as "casual, he is a close friend". Defaults to matching the relationship.
`canDo`	No	What you will do for the people on the call when they ask, such as "look things up in the repo and edit the docs". With it, the voice passes their requests to you (live.requests in wait_for_call) and you answer with reply_to_call_request; it declines anything else. Omit it and nobody can ask you for anything. Name only what you can do and the user would approve.
`voice`	No	GPT-Live voice name; see list_voices
`notify`	No
`record`	No	Phone only: record this call in the user's phone account; the assistant tells the other person the call is recorded. Only when the user asks for a recording.
`channel`	Yes	phone to place a call; meeting to join Zoom, Teams, or Google Meet
`contact`	No	Who is being called, when the user's profile does not already know this number.
`context`	No	What you and the user have been working on that the other party may ask about. Text, or an object: summary (a few sentences), facts, decisions, openQuestions, and details (long reference material). The voice starts with a short version and looks details up when asked; it never recites them.
`language`	No	Language tag such as en or es
`carryFrom`	No	Start with short notes from earlier calls (at most 10). task: earlier calls in this brief's task; contact: earlier calls to the same number (phone only), or false to skip what the user switched on for that contact; calls: these call ids. Only carry what this call needs: the assistant may mention it to the other party, so do not carry one business's details to another unless the objective calls for it.
`objective`	Yes	What the call must achieve, in one or two sentences
`questions`	No	What to find out on the call. The result answers each one.
`rehearsal`	No	Phone only: practice on the user's own phone first, with the user playing the other side
`afterHours`	No	Phone only: call even though it is outside calling hours (8 AM to 9 PM) where the person is. Set only when the user confirms the person expects a call now.
`maxMinutes`	No	Phone calls: at most 60 (default 10). Meetings: at most 240 (default 120).
`mayAgreeTo`	No	What the assistant may agree to without checking back, such as acceptable times or prices
`onBehalfOf`	No	The user's name, spoken in the opening: Hi, I'm calling on behalf of NAME about... Defaults to the name given at setup.
`mustNotShare`	No	Information the assistant must never share
`successCriteria`	No	How to tell the call succeeded

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.3.0Oct 23, 2026

addedInput schema / properties / canDo

Added value: +{
+  "description": "What you will do for the people on the call when they ask, such as \"look things up in the repo and edit the docs\". With it, the voice passes their requests to you (live.requests in wait_for_call) and you answer with reply_to_call_request; it declines anything else. Omit it and nobody can ask you for anything. Name only what you can do and the user would approve.",
+  "maxLength": 500,
+  "type": "string"
+}

First observedv0.1.0Oct 7, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds substantive behavior beyond that: the return shape (ok, the brief as it would be placed, blocking problems, carried-note count) and the brief_incomplete error path with a question to ask the user. Minor deduction because it doesn't say whether the response is a dry-run artifact that can be passed straight to start_call.

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?

Four tight sentences, front-loaded with the identity-defining constraint, then outcomes, then the routing rule. Every sentence carries information an agent needs; nothing is padded.

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 21-parameter tool with no output schema, the description covers the missing piece — return values and the incomplete-brief path — so an agent knows what to expect and how to handle failures. Schema covers the inputs, description covers the outputs; nothing material is absent.

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 description coverage is 95%, so the 21 parameters are already thoroughly documented in the schema; the description adds no field-level meaning beyond two illustrative failure cases (missing setup, refused number). Baseline 3 applies when the schema does the heavy lifting.

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 (validate) and resource (a call brief), with the defining scope constraint: 'exactly as start_call would, without placing a phone call or joining a meeting.' That makes it unmistakable versus start_call and the other call-management 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?

Explicitly names the condition for use ('when unsure whether a brief is complete') and the alternative ('start_call runs the same checks itself'), so an agent knows both when to reach for this and when to skip it. That is exactly the when/when-not/alternative triad.

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

Deploy Server

Check a call brief

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools