Skip to main content
Glama

create_sip_credential

Mint a new SIP credential for a number so a device can register. The registrar generates the username and password and returns them along with the server, port, transport and realm the device needs. Many credentials per number are expected — one per person once an extension is set, or one per device without — up to the number's limit; label each one so it can be told apart later. Pass client_id to carry your own caller reference (e.g. a member id) onto outbound calls from the device, and extension to turn this credential into a person's line with a 4-digit internal number the workspace's other devices can dial — internal calls connect directly and are not charged, and app devices can then be attached to the same line with a connection code. Fails with numbers.credential_limit_reached when the number is full (revoke one to free a slot), numbers.extension_taken when another credential already uses that extension, numbers.extension_invalid when it is not exactly 4 digits, and numbers.sip_provisioning_failed when the registrar cannot be reached, in which case nothing is created.

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": {
      "number_id": "<number_id>"
    },
    "name": "create_sip_credential"
  }
}

Input Schema

NameRequiredDescriptionDefault
labelNohuman label naming the device this credential is for, e.g. 'Reception desk phone' or 'Odoo prod'
purposeNoRequired on tools that read data or reports; recommended on every tool. One sentence: what you are doing and why (for example "finding this caller's open ticket to answer them"). Building a report, dashboard, analytics or an export is a SautiDesk Pro feature done by the report tools, not by pulling records.
client_idNooptional free-text caller reference the registrar substitutes for the caller number on outbound calls from this device — use it to carry your own identifier, such as a member id. Not a phone number; the number the device may present is derived server-side.
extensionNooptional internal extension — exactly 4 digits, unique across the workspace. The workspace's other registered devices reach this one by dialling it, and those calls connect directly between the devices and are not charged. Never reaches a carrier.
number_idYestenant number UUID to mint a credential for

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the sparse annotations (openWorldHint=false, destructiveHint=false) by stating that the registrar generates the username and password server-side and returns them with server, port, transport and realm. It enumerates four concrete failure codes, including which one is retryable-by-freeing-a-slot and that sip_provisioning_failed is atomic ('nothing is created'). It also discloses that internal extension calls are not charged and never reach a carrier.

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?

Front-loaded with the core action and result, then escalates to the optional extension/client_id semantics and finally the failure modes in a useful order. It is a single dense paragraph with several long clauses, so it is heavier than strictly necessary, but almost every sentence carries operational information.

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

Completeness5/5

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

With no output schema, the description compensates by naming exactly what comes back (username, password, server, port, transport, realm). For a mutation tool with a limit and four distinct error conditions, it covers prerequisites, side effects, and failure atomicity, so an agent has everything needed to call it and handle the result.

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 coverage is 100%, so the baseline is 3, but the description adds genuine meaning: client_id carries a caller reference onto outbound calls and is not a phone number, and extension turns the credential into a person's line with a 4-digit internal number reachable by other workspace devices. It also reinforces label's purpose as future disambiguation. It does not add anything for number_id beyond the schema, which keeps it below a 5.

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: 'Mint a new SIP credential for a number so a device can register.' It immediately scopes the tool to a number UUID and a provisioning outcome, which distinguishes it from sibling lifecycle tools like rotate_sip_credential or revoke_sip_credential without needing their schemas.

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?

Explains the expected multiplicity ('one per person once an extension is set, or one per device without') and tells the caller to use the label to disambiguate later. It also gives remediation when the limit is hit ('revoke one to free a slot') and describes the extension path that lets app devices attach via a connection code. It stops short of explicitly naming sibling alternatives for rotation or update, which keeps it from a 5.

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