Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@fleet-dispatch Call me and ask whether to drop the users table or skip the migration."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A blocked Claude Code session phones you. You say the answer out loud. The session unblocks and continues.
A stuck session costs the forty minutes it sits idle, not the eight seconds the decision takes. One-way alerts don't fix that because you still have to walk back and type. This is a two-way channel: one MCP tool, call_me(context, question, options), that places a real outbound call through CALL-E, blocks until you answer, and returns your spoken decision to the session.
Node 24 or newer.
A CALL-E account. New accounts get 20 free calls. Create an API key at https://dashboard.heycall-e.com/account/api-keys.
A phone number CALL-E can dial. Coverage is 40+ countries; see the regions table. India (+91) is on the international line.
Related MCP server: phonecall-mcp
No code of ours involved. This uses CALL-E's own CLI:
export CALLE_API_KEY=calle_...
npx @call-e/calle@latest calls create \
--phone "+91XXXXXXXXXX" \
--task "Call this person, say 'this is Fleet Dispatch, testing', and ask if they can hear you clearly." \
--wait --jsonIf your phone rings, everything else will work.
git clone git@github.com:Yashodeeps/fleet-dispatch.git ~/fleet-dispatch
cd ~/fleet-dispatch && npm install && npm test
cat > .env <<'EOF'
CALLE_API_KEY=calle_...
FLEET_DISPATCH_PHONE=+91XXXXXXXXXX
FLEET_DISPATCH_REGION=IN
EOF
claude mcp add --scope user --transport stdio fleet-dispatch -- node ~/fleet-dispatch/src/server.tsThe server reads .env next to its source. Variables set in the shell or via claude mcp add --env take precedence. .env is gitignored. User scope means every session on this machine gets the tool.
The Skill holds the policy for when a session should dial and when it should not.
mkdir -p ~/.claude/skills && cp -r ~/fleet-dispatch/skill ~/.claude/skills/fleet-dispatchIn any claude session:
Call me and ask whether to drop the users table or skip the migration.Your phone rings. Say "skip it". The tool returns:
{
"answered": true,
"decision": "Skip the migration",
"chosen_option": "Skip the migration",
"reasoning": null,
"reason": "answered",
"call_id": "call_...",
"summary": "...",
"transcript": [{ "speaker": "bot", "text": "..." }, { "speaker": "user", "text": "..." }]
}Set FLEET_DISPATCH_DRY_RUN=1 instead of CALLE_API_KEY and the server answers with the first option after a moment, without dialing. Useful for wiring up a new machine or recording a demo.
Variable | Required | Meaning |
| yes, unless dry run | CALL-E API key |
| yes | Your number in E.164, the only number this server will ever dial |
| no | Country code hint for routing, e.g. |
| no | BCP 47 locale hint, e.g. |
| no |
|
call_me(context, question, options?, default?, session?, timeout_seconds?)
Blocks up to timeout_seconds (default 300, max 900). Claude Code's MCP tool timeout defaults to many hours, so nothing else to configure.
answered: true means you gave and confirmed a decision.
reason: hold means you told it to wait. The default is never applied over an explicit hold.
reason: timeout or failed:<code> returns default if one was given, otherwise null so the session halts.
The phone number comes from the environment, never from the model. The model cannot choose whom to call.
Every non-dry-run tool call places one real phone call to FLEET_DISPATCH_PHONE and consumes CALL-E credit.
There is no retry. A missed call returns the fallback and the Skill tells the session not to call again for the same question.
Cancel by hanging up. The call ends and the session gets reason: unclear or hold depending on what was said.
Place a real phone call to the engineer who owns this session and block until they answer. Use only when you are blocked on a decision that they must make: ambiguous spec, destructive or irreversible action, failing migration, spending money. Never for lint, style, or anything you can decide from the code. The call costs money and interrupts a person. Returns their spoken decision as JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | What you were doing and why you are blocked. One to three sentences. It is read aloud, so no paths, hashes, or code. | |
| default | No | What to do if the call is not answered. Omit to halt and wait at the terminal. Never set this for destructive actions. | |
| options | No | Concrete choices, each short enough to say aloud. Put the one you would pick first. Omit for open-ended questions. | |
| session | No | Session label spoken on the call. Defaults to the project directory name. | |
| question | Yes | The single decision you need. One sentence, read aloud. | |
| timeout_seconds | No | How long to wait for an answer. Default 300. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses real-world side effects: the call costs money and interrupts a person. It also reveals the blocking behavior and that the return value is the engineer's spoken decision as JSON. Since annotations do not convey these consequences, the description carries that burden fully and successfully.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and every sentence earns its place: action, blocking behavior, triggering conditions, forbidden uses, real-world cost, and return format. It is front-loaded with the essential action and then gives decision criteria. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-stakes tool with 6 parameters and no output schema, the description still covers the essential operational context: when it is appropriate, what it does, what the user experience is, and what it returns. The input schema covers parameter mechanics, and the description covers real-world consequences and guardrails completely enough for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description still adds important semantic guidance beyond parameter names: context is read aloud so must avoid paths/hashes/code, options must be short enough to speak, default should never be set for destructive actions, and omitting default halts and waits. This is exactly the kind of usage nuance an agent needs to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Place a real phone call to the engineer who owns this session and block until they answer.' This makes the tool's core function unmistakable and distinguishes it from generic messaging or async notification tools. The title and description align without relying on the tool name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool ('only when you are blocked on a decision that they must make') and gives concrete examples like ambiguous spec, destructive action, failing migration, and spending money. It also names the negative case: 'Never for lint, style, or anything you can decide from the code.' This is unusually clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0call_meWith only one tool available, there is no possibility of confusing it with another. The tool's purpose is clearly described and unique within the server.
The single tool name 'call_me' follows a verb_noun pattern, but with only one tool there is no established pattern to evaluate for consistency. It is internally consistent but offers limited evidence of a naming convention.
The server is named 'fleet-dispatch', implying a broad dispatch domain, yet it exposes only a single tool for calling an engineer. This is far too few tools for the apparent scope and leaves the core functionality unaddressed.
The tool surface is severely incomplete for a fleet dispatch server—there are no tools for managing fleets, routes, vehicles, or dispatches. The single call tool is an outlier that does not cover the domain implied by the server name.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Claude makes real phone calls for you — in many languages, with transcript and outcome back in chat.
Give AI agents a phone: outbound AI calls that return a summary, transcript, and extracted fields.
Calls your phone when an AI task finishes or is blocked — hear it, say what's next.
Give your AI agent a phone. Place outbound calls to US businesses to ask, book, or confirm.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Yashodeeps/fleet-dispatch'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
