Skip to main content
Glama
Sign In

TaskLite

by net.tasklite
OverviewDiscussionsAdmin

start_telephony_connection

Start connecting an app to a phone system (PBX) and get the one-time link the CUSTOMER opens to type the API token themselves. The token never passes through the chat, you or the logs: do not ask for it, do not accept it pasted. Send the link to the customer as is. It works once, for 24 hours, and is spent only after the token passes a check against the PBX (a typo can be fixed on the same page). Calling again makes a new link and replaces the unused one; the stored token is kept until a new one is typed. Pick the provider from list_telephony_providers. For paycall pass publicConfig.baseUrl, the server address of that customer's tenant, e.g. https://master.ippbx.co.il/ippbx_api/v1.4/api/info (https only, must end with /api/info). Owner or admin of the app. Afterwards: get_telephony_connection shows connected, test_telephony_connection proves it, configure_telephony_mapping says where calls go.

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": {
      "appId": "<appId>",
      "provider": "<provider>"
    },
    "name": "start_telephony_connection"
  }
}

Input Schema

NameRequiredDescriptionDefault
appIdYesApp id or slug (from list_apps / create_app)
providerYesProvider id from list_telephony_providers, e.g. paycall
publicConfigNoNon-secret settings only, per the provider's fields, e.g. { baseUrl }
organizationIdNoOrganization id; defaults to the credential organization when omitted

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations cover only the safety profile; the description adds the crucial behavior the agent cannot infer: the link works once for 24 hours, is spent only after the token passes a PBX check, a re-call replaces the unused link while keeping the stored token, and the token must never pass through chat or logs. This is exactly the operational context annotations cannot convey.

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?

Security guidance and the provider/format constraint are front-loaded in a dense, useful block. It runs long with several clauses, but each carries actionable content; only minor tightening is possible.

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 non-idempotent, non-destructive mutation with no output schema and a nested object, the description covers security, one-time semantics, expiry, replacement behavior, and next steps. Return format is left to siblings, which is acceptable given the stated follow-up tools.

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 real meaning beyond it: publicConfig.baseUrl must be the tenant server address, https only, ending in /api/info, with a concrete example. That constrains the nested object in ways the schema's additionalProperties:string does not.

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 ('Start connecting an app to a phone system (PBX)') plus the concrete outcome (a one-time link the customer opens). The name-plus-description clearly separates it from disconnect_telephony, get_telephony_connection, test_telephony_connection, and configure_telephony_mapping.

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

Usage Guidelines5/5

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

Gives explicit routing: pick provider from list_telephony_providers, requires owner or admin of the app, and names the follow-up tools (get_telephony_connection confirms, test_telephony_connection proves, configure_telephony_mapping routes calls). Alternatives and sequence are unambiguous.

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

All TaskLite toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources