TaskBullet

Place call

place_call

DestructiveIdempotent

Places one human phone call to a US or Canada number to ask up to 20 questions, gather answers, and return results for scheduling, information, or account tasks.

Instructions

Place one human phone call. The hold is the full call: the tier minimum for the first minute, then the per-minute rate for each additional minute. Default max_minutes is 5, so a tier 1 US or Canada call holds $6.50. Raise max_minutes on that call to hold more. record_call must be false or omitted. Only US and CA are live. A question is {"id","ask","type"?}: id up to 80 characters, ask up to 1000 characters, at most 20 questions. goal is at most 4000 characters. Idempotency key is required. Poll get_call, or pass callback_url. validate_call checks the body and places no hold.

Input Schema

Name	Required	Description
`goal`	Yes
`phone`	Yes	US or Canada number. 801-414-4664, (801) 414-4664, and +1 801 414 4664 are accepted and stored as E.164.
`script`	No
`purpose`	Yes
`deadline`	Yes	ISO-8601. Needs 60 minutes of weekday 09:00–17:00 recipient-local, unless allow_outside_business_hours is true.
`language`	No	en, fil, tl, war, or ceb. Default en.
`extension`	No	Optional digits. Passed into the VA instructions. Not billed.
`questions`	Yes	One to 20 questions. Each item is {id, ask, type?}.
`max_minutes`	No	Default 5. Maximum 60. The hold covers this many minutes.
`record_call`	No	False or omit. True is rejected: recording is not available.
`script_mode`	No
`time_window`	No	Optional 24-hour HH:MM-HH:MM in the recipient time zone. Example: 09:00-17:00. End must be after start.
`callback_url`	No
`instructions`	No	Outranks script wording. The extension is appended for the VA.
`max_attempts`	No	Default 3. Maximum 5.
`on_behalf_of`	Yes
`business_name`	Yes
`idempotencyKey`	Yes	Same value as the REST Idempotency-Key header.
`retry_preference`	No
`shareable_contact`	No
`recipient_timezone`	No	IANA zone. Omit it and TaskBullet infers a US or Canada area code. An uninferable number needs this field.
`allowed_disclosures`	No
`consent_attestation`	Yes	Must be true.
`allow_outside_business_hours`	No	Set true only after the customer confirms the call may happen outside weekday 09:00–17:00 in the recipient time zone. The deadline then needs 60 minutes of clock time. Omit or false keeps the weekday business-hour rule.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.2.0Oct 22, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing the billing/hold model (first-minute tier minimum, per-minute thereafter, $6.50 hold at the 5-minute default), the interaction between max_minutes and the hold, the hard rejection of record_call=true, and the live-market restriction. These are exactly the operational facts (cost exposure, irreversible spend, geographic limits) an agent needs before a destructive, open-world write.

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-loaded with the action, then the cost model, then constraints and alternatives. Nearly every sentence carries a distinct fact, though the terse fragment style ("Only US and CA are live.") makes the block dense to parse at 24 params.

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?

An output schema exists and annotations carry the safety profile, so the description needn't cover returns. It covers the highest-risk constraints (spend, idempotency, recording rejection, market and business-hour rules), leaving only peripheral fields undocumented.

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?

With 24 params at 58% schema coverage, the description compensates by specifying the questions object shape, its 80/1000-char and 20-item limits, the 4000-char goal cap, required idempotency key, and the pricing/semantics of max_minutes. It leaves several lower-risk params (script, purpose, language, script_mode, shareable_contact, etc.) to the 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?

States a specific verb+resource ("Place one human phone call") plus scope limits (US and CA only, one call, human VA). It also explicitly contrasts itself with sibling validate_call, so an agent can distinguish the two without opening either schema.

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?

Names the polling path (get_call) and callback_url alternative, and clarifies that validate_call checks the body without placing a hold, which is clear routing guidance. It stops short of an explicit when-not/preconditions statement (e.g. that consent_attestation must be true before placing).

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

Deploy Server