- The block - two keys
- The registry, in full - two ids, and it is closed
- What the registry decides for you - effect, parameters, description
- Turning it on - the same two lists
- Advanced - resolving on SLNG
- Troubleshooting - two refusals by name
tools/end_call.yaml
unmute init scaffolds, so a new agent can hang up from its first
run.
The block
string
required
Accepts
end_call or send_sms from the registry below. No id is inferred. send_sms
is SLNG only.string
Instruction the runtime gives the model as the prebuilt runs. For
end_call, use it for
a final line or action before ending. Omit to add no custom instructions to the
prebuilt.The registry, in full
Two rows. The registry is closed: you cannot add to it from a package, and
there is no plugin seam. Adding a prebuilt means a row in the compiler plus a
lowering for each target, which is a change to Unmute, not to your agent.
end_call compiles on every target. send_sms is a capability SLNG curates
and compiles on the slng target only; a code target refuses it by name. It
takes one setting from the package, the sender:
tools/send_sms.yaml
from_number is a literal number in international format starting with a plus
sign, and it is the only key inject: may carry here: SLNG requires the
sender on the attachment and lets the model supply the recipient and the body.
SLNG reads the Twilio credentials from your vault under TWILIO_ACCOUNT_SID
and TWILIO_AUTH_TOKEN, so unmute deploy checks both. Pair it with a
source: conversation variable so the number
the caller confirmed is recorded on the call.
So read this page as a list of two things that exist, not as a catalog to
browse. If what you want is neither, it is a
webhook, a Python handler, or an
MCP server.
What the registry decides for you
The effect.end_call implies ends_conversation, and writing anything else
fails rather than being quietly ignored:
description out and the registry
default is used.
What the two targets emit for the bare file
What the two targets emit for the bare file
From a real compile of the bare file above, on each target:Same tool, same description, two lowerings.
unmute init scaffolds the LiveKit
one; the shipped examples that declare a Pipecat target get the other.description when the agent needs a narrower instruction, for
example telling it to confirm before hanging up. Yours is added on top of the
default rather than replacing the tool’s behavior.
Use builtin.instructions when the model must do something at execution time:
ends_conversation effect.
Turning it on
The same two lists as any other tool:agent.yaml
Advanced
Resolving on SLNG
SLNG already offersend_call as one of its own curated capabilities, so
unmute deploy’s preflight check has to match your reference against it
before pushing. It matches by the tool file’s name, tools/end_call.yaml,
never by the builtin.id you selected inside it.
That is fine as written here, because the file is named end_call too. It
stops being fine the moment you rename the file to describe what it does rather
than the capability it selects.
Troubleshooting
An id the registry does not hold
An id the registry does not hold is refused by name. Every line below is prefixed with the target instance that refused it, so a fresh scaffold, which has onelivekit instance, reads like this:
The SLNG preflight says the organisation has no tool of that name
A filetools/hang_up.yaml holding builtin: {id: end_call} compiles and
validates, but the organisation has no tool named hang_up. The preflight then
reports it absent, even though the capability exists:
builtin: file’s name matching its id.
Where to go next
Knowledge bases
Answer from a folder of your own documents.
Tools
Return to all eight execution blocks.