Skip to main content
Glama

Create VOIP List

create_voip_list
Destructive

[write] Creates an empty saved call list (the result has its id and uuid); fill it with add_voip_list_members. voip_list_country is the calling code (e.g. 90) that completes national numbers starting with 0.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "voip_list_title": "<voip_list_title>"
    },
    "name": "create_voip_list"
  }
}

Input Schema

NameRequiredDescriptionDefault
voip_list_titleYes
voip_list_countryNo
voip_list_descriptionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare a write, non-idempotent, open-world tool. The description adds value beyond them by disclosing that the created list is empty and that the response contains an id and uuid, which matters since no output schema exists. It doesn't mention permissions or duplicate-title behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with the write marker front-loaded, the create-then-fill relationship clear, and the country nuance packed into a compact parenthetical. Nothing is wasted.

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 three-parameter creation tool with no output schema, the description covers the object created, the follow-up action, the return identity, and the trickiest parameter. Only the optional description field and duplicate-handling behavior remain unaddressed.

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 coverage is 0%, so the description carries the load; it explains voip_list_country as the calling code that completes national numbers starting with 0, which is genuinely non-obvious. However, voip_list_title and voip_list_description get no treatment, leaving two of three parameters undefined.

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 and resource ('Creates an empty saved call list') and immediately distinguishes the outcome from the sibling that populates it by naming add_voip_list_members.

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?

Gives clear workflow guidance: create the empty list here, then fill it with add_voip_list_members. It does not cover when to prefer edit_voip_list or how this relates to create_voip_campaign, so it stops short of explicit exclusions.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.