Skip to main content
Glama

callingly

by com.callingly
OverviewDiscussionsAdmin

Manage phone numbers and number pools

manage_number

Change a phone number's or number pool's call and SMS settings, rename a number, pool or caller ID, generate or reset its welcome and voicemail greetings, mark a number dispatch, create a pool, or add/remove a number from a pool. Read ids and current settings with get_numbers first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoNew name (max 255), for rename and create_pool.
textNoWhat the greeting says (max 1000), for generate_welcome / generate_voicemail.
actionYesupdate_settings: change the given settings (number_id or number_pool_id; a pool applies them to every member). rename: set name (number_id, number_pool_id or callerid_id). reset_welcome: remove the custom welcome audio. generate_welcome / generate_voicemail: synthesize text with voice_id. set_dispatch: set enabled. create_pool: name, rotation_mode, number_ids, team_ids. add_to_pool / remove_from_pool: number_pool_id and number_id.
changesNoupdate_settings only. Field → new value, for the fields that change: is_record, is_whispertext (call screening), is_welcome, is_sms_missed_call (booleans); routing (team|agent|ivr); call_mode (roundrobin|simultaneous|simultaneous_all); team_id, fallback_id, voicemail_team_id (0 = lead's team), user_id (routing agent), tag_id, callerid_id; lead_owner_routing (ignore|owner_first|only_owner|only_team); ivr_menu (full menu, digit → "user_<id>" or "team_<id>"); sms_missed_call_body; ai_sms_agent_id + ai_sms_team_id; ai_voice_agent_id + ai_voice_mode (always|fallback|after_hours).
enabledNoset_dispatch: true to turn on, false to make the number regular again.
team_idsNocreate_pool, or a pool's update_settings: the teams that use the pool (replaces the list).
voice_idNoA voice_id from get_numbers (number_id or number_pool_id), for generate_welcome / generate_voicemail.
number_idNoThe phone number to act on, from get_numbers.
number_idsNocreate_pool: numbers to put in the new pool.
callerid_idNoA caller ID from get_numbers' caller_ids, for rename only.
rotation_modeNoPool caller ID rotation, for create_pool (default round_robin) and a pool's update_settings.
number_pool_idNoThe number pool to act on, from get_numbers.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / action / description
      Previous value: -"update_settings: change the given settings (number_id or number_pool_id; a pool applies them to every member). rename: set name (number_id, number_pool_id or callerid_id). reset_welcome: remove the custom welcome audio. generate_welcome / generate_voicemail: synthesize text with voice_id. set_dispatch / set_forwarding: set enabled (forwarding needs user_id to turn on). create_pool: name, rotation_mode, number_ids, team_ids. add_to_pool / remove_from_pool: number_pool_id and number_id."New value: +"update_settings: change the given settings (number_id or number_pool_id; a pool applies them to every member). rename: set name (number_id, number_pool_id or callerid_id). reset_welcome: remove the custom welcome audio. generate_welcome / generate_voicemail: synthesize text with voice_id. set_dispatch: set enabled. create_pool: name, rotation_mode, number_ids, team_ids. add_to_pool / remove_from_pool: number_pool_id and number_id."
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "update_settings",
-  "rename",
-  "reset_welcome",
-  "generate_welcome",
-  "generate_voicemail",
-  "set_dispatch",
-  "set_forwarding",
-  "create_pool",
-  "add_to_pool",
-  "remove_from_pool"
-]New value: +[
+  "update_settings",
+  "rename",
+  "reset_welcome",
+  "generate_welcome",
+  "generate_voicemail",
+  "set_dispatch",
+  "create_pool",
+  "add_to_pool",
+  "remove_from_pool"
+]
    • changedInput schema / properties / enabled / description
      Previous value: -"set_dispatch / set_forwarding: true to turn on, false to make the number regular again."New value: +"set_dispatch: true to turn on, false to make the number regular again."
    • removedInput schema / properties / user_id
      Removed value: -{
-  "description": "set_forwarding with enabled true: the rep whose calls the number forwards to.",
-  "type": "integer"
-}
  2. Added

TDQS

A3.9/5.0
Behavior3/5

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

Annotations supply only destructiveHint=false, so the description carries most of the burden. It discloses the read-before-write prerequisite and the breadth of mutations, but is silent on permission requirements, reversibility, and the fact that reset_welcome discards custom audio (that detail lives only in the action enum). Adequate but with clear gaps for a 9-action mutation tool.

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?

The action inventory is front-loaded in one dense sentence followed by a short imperative prerequisite, so the agent sees scope before the setup step. The enumeration is long but each action listed earns its place in a dispatcher-style tool.

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?

For a 12-parameter tool with a nested `changes` object and no output schema, the description plus the rich schema give enough to call it correctly, and the get_numbers prerequisite closes the main gap. It could still say more about mutation side effects and per-action requirements to be fully self-sufficient.

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 100%, so the schema already documents all 12 parameters and the per-action enum semantics. The description only adds the provenance hint that ids come from get_numbers, which the schema largely implies already; baseline 3 is appropriate.

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?

The description names concrete verbs and resources across the full action space: change call/SMS settings, rename a number/pool/caller ID, generate or reset greetings, set dispatch, create a pool, and add/remove pool members. It also clearly scopes the tool to both numbers and number pools, which distinguishes it from read-only siblings like get_numbers.

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?

It gives an explicit prerequisite — "Read ids and current settings with get_numbers first" — which routes the agent to the correct read tool before mutating. It does not, however, state when-not conditions or how to choose between this tool and adjacent mutating siblings (e.g. delete_number_item, update_settings).

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

All callingly toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources