CALL-E For Cursor
Use this skill when the user wants Cursor to use CALL-E for setup checks,
authentication recovery, phone call planning, planned call execution, or call
status inspection.
This Cursor plugin is MCP-first. Prefer the Cursor MCP tools exposed by the
bundled
server whenever they are available:
Use the CLI fallback only when Cursor MCP tools are unavailable or the user
explicitly asks to verify CALL-E through the CLI.
When to use
Use this skill for:
- verifying CALL-E setup in Cursor
- checking that the MCP server is connected
- recovering from missing or expired CALL-E MCP authentication
- planning a phone call
- running a planned call after planning returns complete run credentials
- checking a call run status
- reporting the final call summary, details, and transcript when a call reaches
a terminal status
Do not use this skill when the user only wants a call script, roleplay,
simulated conversation, or general contact lookup that does not require CALL-E.
Safety and consent
- Real phone calls may contact external people or businesses.
- Always use plan_call before run_call.
- Only call run_call when the user clearly intends to place the call.
- Preserve plan_id and confirm_token exactly.
- If the user asked only to verify setup or only to plan, do not run the call.
- Do not guess phone numbers, country codes, language, region, plan_id,
confirm_token, or run_id.
- Do not expose OAuth tokens, bearer tokens, authorization codes, callback URLs,
refresh tokens, or access tokens.
- Do not configure CALL-E run_call for auto-run.
MCP readiness
Use this flow whenever this Cursor plugin is actively invoked for a CALL-E
request. Run it before call planning, when setup is uncertain, when auth fails,
or when the user asks to verify CALL-E setup:
- Confirm the MCP server is connected.
- Confirm that , , and are available.
- If Cursor asks to authorize the MCP server, use Cursor's MCP
authorization flow and continue after authorization completes.
- Never ask the user for OAuth tokens, bearer tokens, authorization codes,
callback URLs, refresh tokens, or access tokens.
- If the MCP server cannot be connected or authorized, use the CLI fallback.
Setup verification must not place a real phone call. Use only tool discovery,
authorization recovery, and
when the user explicitly asks to plan.
MCP call flow
- Use first.
If the user has not provided enough explicit fields for , call
it with set to the latest user message verbatim so CALL-E can
ask for missing details.
- Read the returned and .
- If the user's request is to place a call, immediately use with
the exact and returned by planning.
- Do not ask for a second confirmation between and .
- Read the returned . Preserve it exactly.
- After , wait 60 seconds before the first request
unless the call already returned a terminal status.
- Keep using with that exact until the call reaches a
terminal status or the user asks you to stop. Poll every 5 to 10 seconds
after the first status check.
- Use only with a known .
Terminal statuses include
,
,
,
,
,
,
,
, and
.
For non-terminal statuses, reply with progress in this shape:
text
Phone call is in progress! Progress:
- <HH:MM:SS message>
Use one bullet per
item, preserving the order returned by CALL-E.
For each item, prefer the event
formatted as
plus
.
If
is missing, use the message by itself. If there is no activity, use
when a status exists; otherwise use
- Waiting for the next status update.
Do not include the final summary,
details, or transcript until a terminal status is returned.
When the call reaches a terminal status, reply with the final call result,
including these sections in this order:
text
[Status]
<status>
[Call Summary]
<post_summary or summary or message>
[Details]
Callee Number: <primary callee or Not available>
Duration: <duration or Not available>
Time: <start/end time or Not available>
Call id: <call_id or Not available>
[Transcript]
<transcript or Not available.>
If the user asked for extra final content, such as key takeaways or next steps,
add it after
under a short heading. Base all final sections only
on the JSON returned by
or
; do not invent a
transcript.
CLI fallback
All CLI commands run from this Cursor plugin must include the CALL-E integration
attribution environment:
bash
env CALLE_SOURCE=cursor CALLE_INTEGRATION=cursor_plugin CALLE_INTEGRATION_VERSION=0.1.0
Use the first command form that works.
Prefer the repository-local CLI when the current workspace contains it:
bash
env CALLE_SOURCE=cursor CALLE_INTEGRATION=cursor_plugin CALLE_INTEGRATION_VERSION=0.1.0 node packages/cli/bin/calle.js
If the repository-local CLI is unavailable, use the global command:
bash
env CALLE_SOURCE=cursor CALLE_INTEGRATION=cursor_plugin CALLE_INTEGRATION_VERSION=0.1.0 calle
If neither command works, use the pinned npm package through
:
bash
env CALLE_SOURCE=cursor CALLE_INTEGRATION=cursor_plugin CALLE_INTEGRATION_VERSION=0.1.0 npx -y @call-e/cli@0.3.2
Only tell the user to install the CLI globally if
is unavailable,
network access is blocked, or the user explicitly wants a persistent global
command.
Use CLI fallback readiness commands in this order:
- Check CLI availability with .
- Run .
- If reports , run blocking and
keep that command running until it exits.
- After login completes, run .
- Confirm that , , and are available.
If a CLI command returns
, switch to the CLI fallback readiness
flow, complete login, and then retry the original operation after login
completes.
Use
for exact CLI command examples, supported options,
and JSON handling rules.