Skip to main content
Glama

lines_update

Rename a line, make it the default, choose the published inboundAgentId that answers its callers (gateway lines; null stops answering), set testNumbers (customer gateway and Twilio lines), rotatePairing to issue a new pairing code and sign the paired device out, or capacity (Twilio lines: concurrent calls 1–10; phone gateways, SAGOT numbers and shared routes carry one call). The deployment also caps concurrent calls overall. On a SAGOT number line testNumbers can only remove numbers (add them with lines.verifyNumber). carrierRate {amountPerMinute, currency, increment minute|second} (null clears) records what your carrier charges on lines whose provider doesn't report prices (phone gateway SIM): calls then show an estimated carrier cost. Twilio lines report Twilio's actual price instead; SAGOT number lines include telecom in SAGOT's charge. mode: "live" (admin, not an assistant) lets a SAGOT number line call any number in a supported country once SAGOT has turned live calling on; otherwise it fails LIVE_MODE_UNAVAILABLE.

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": {
      "workspaceId": "<workspaceId>",
      "id": "<id>",
      "revision": "<revision>"
    },
    "name": "lines_update"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
modeNo
nameNo
capacityNo
revisionYes
isDefaultNo
carrierRateNo
testNumbersNo
workspaceIdYes
rotatePairingNo
inboundAgentIdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / carrierRate
      Added value: +{
      +  "anyOf": [
      +    {
      +      "properties": {
      +        "amountPerMinute": {
      +          "maximum": 100000,
      +          "minimum": 0,
      +          "type": "number"
      +        },
      +        "currency": {
      +          "pattern": "^[A-Z]{3}$",
      +          "type": "string"
      +        },
      +        "increment": {
      +          "default": "minute",
      +          "enum": [
      +            "minute",
      +            "second"
      +          ],
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "amountPerMinute",
      +        "currency"
      +      ],
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ]
      +}
  2. First observed

TDQS

A3.6/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and delivers: null inboundAgentId stops answering, rotatePairing issues a new code and signs the paired device out, capacity caps and deployment-level caps, carrierRate null-clears and drives estimated cost, and the LIVE_MODE_UNAVAILABLE failure. It omits concurrency/permission behavior beyond mode, so not a 5.

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

Conciseness3/5

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

The content is dense and mostly earns its place, but it is delivered as a single run-on paragraph mixing many parameters, parentheticals, and product-line caveats. It is not structured or front-loaded per parameter, making it hard to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter mutation with no annotations and no output schema, the description covers field semantics and many behavioral quirks well. But it never explains revision (the required concurrency token) or what the call returns, which are meaningful gaps for a safe update.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain parameters, and it covers most meaningful ones: name, isDefault, inboundAgentId, testNumbers, rotatePairing, capacity ranges, carrierRate structure, and mode enum semantics. It does not explain revision (optimistic concurrency token) or the id/workspaceId identifiers, leaving gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names specific verbs and resources for each updatable field (rename, make default, choose inboundAgentId, set testNumbers, rotatePairing, set capacity, carrierRate, mode). An agent can tell this is a line-settings mutation distinct from lines_create/lines_delete. It lacks an explicit one-line 'update a line' framing, but the enumeration is concrete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives targeted when-to guidance for a few cases: SAGOT testNumbers can only remove numbers (add via lines.verifyNumber), and mode:'live' requires admin and fails LIVE_MODE_UNAVAILABLE. However, there is no general statement of when to use this tool versus siblings like lines_create or lines_delete, so usage is mostly implied.

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.

Resources