Skysay

Attach sip connection number

attach_sip_connection_number

Destructive

Bring your own SIP trunk: create, read or change a carrier SIP connection and its numbers through the same service as /v1/sip-connections. Passwords are write-only and never returned. Attaching a number for incoming calls, and check_sip_connection_number_ownership, place one Skysay verification call to that number (rate limited per number and per workspace); outbound with the number is refused until its ownership is confirmed. start_sip_connection_test_call places one billed call (calls:write) from the number to the given phone; check_sip_connection_reachability sends one SIP OPTIONS to the carrier server. No carrier settings change.

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": {
      "e164": "<e164>",
      "connection_id": "<connection_id>"
    },
    "name": "attach_sip_connection_number"
  }
}

Input Schema

Name	Required	Description
`e164`	Yes	The number in E.164 form. Premium-rate, shared-cost and unknown number types are refused.
`inbound`	No	Defaults to whether the connection carries inbound calls.
`agent_id`	No	A published agent that answers incoming calls.
`outbound`	No	Defaults to whether the connection carries outbound calls.
`project_id`	No
`connection_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026

TDQS

B3.1/5.0

Behavior4/5

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

Beyond the destructive/non-idempotent annotations, it discloses that attaching triggers a verification call to the number, that the call is rate limited per number and per workspace, that passwords are write-only and never returned, and that outbound is blocked until ownership confirmation. Those are substantive operational facts an agent would otherwise not know. It loses a point for embedding unrelated sibling behavior (test calls, SIP OPTIONS) that muddies what this specific call will do.

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

Conciseness2/5

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

The content is not front-loaded: the actual attach operation appears after a generic SIP-trunk preamble, and a long run-on sentence lumps in behaviors of three other tools. Several clauses about start_sip_connection_test_call and check_sip_connection_reachability do not earn their place in this tool's definition.

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 a destructive, non-idempotent 6-parameter mutation with no output schema, the description covers the verification/rate-limit side effects but omits what happens on failure, whether an existing attachment is reassigned, and how the inbound/agent_id defaults interact with connection settings. It is adequate but leaves real gaps for a destructive operation.

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 67%, so the schema already explains e164, inbound, outbound, and agent_id. The description adds no parameter-level detail of its own and leaves connection_id and project_id undocumented in both places. The note that premium-rate/shared-cost numbers are refused comes from the schema, not the description, so the description adds little semantic value here.

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

Purpose3/5

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

The description opens with a family-level statement about BYO SIP trunking ("create, read or change a carrier SIP connection and its numbers") rather than a clear verb+resource for this tool. "Attaching a number for incoming calls" buried mid-paragraph is the only phrase that identifies the actual operation. An agent cannot cleanly separate this from get_sip_connection, update_sip_connection, or detach_sip_connection_number based on the opening.

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 names several siblings (check_sip_connection_number_ownership, start_sip_connection_test_call, check_sip_connection_reachability) and states a real prerequisite: outbound is refused until ownership is confirmed. However, it never says when to use this tool instead of detach_sip_connection_number or create_sip_connection, and the sibling mentions read as descriptions of those tools rather than explicit routing guidance.

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

All Skysay tools Inspect

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.