Tools - Talqing

Every tool on the server is one API endpoint. Its name is the endpoint’s operation name, its description starts with the HTTP method and path, and its arguments mirror the HTTP call: path and query parameters at the top level, the request body under body. The API reference and the SDKs describe the same operations.

Arguments mirror the HTTP call

assign_phone_number is POST /v1/telephony/phone-numbers/{number_id}/assign. Its arguments:

{
  "number_id": "9c1f4b8e-7a52-4c0d-b3e6-1d2f8a4c6b90",
  "body": {
    "agent_id": "4b7e2a10-5c93-4e18-8f6a-0d3b9c1e5f27"
  }
}

are sent as:

curl -X POST https://api.talqing.com/v1/telephony/phone-numbers/9c1f4b8e-7a52-4c0d-b3e6-1d2f8a4c6b90/assign \
  -H "Authorization: Bearer $TALQING_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"agent_id": "4b7e2a10-5c93-4e18-8f6a-0d3b9c1e5f27"}'

Query parameters sit at the top level too: list_calls takes agent_id, status, batch_id, start, end, limit and offset beside each other. The response is the API’s JSON body unchanged; an error is the API’s error envelope with isError set.

Names

Tool names are the operation names the SDK method names are derived from:

Tool	HTTP	SDK method
`list_agents`	`GET /v1/agents`	`agents.list`
`publish_agent`	`POST /v1/agents/{agent_id}/publish`	`agents.publish`
`run_task`	`POST /v1/task-runs`	`taskRuns.create`
`get_tool_version`	`GET /v1/tools/{tool_id}/versions/{version}`	`tools.versions.get`

Your client’s tool list is the complete inventory. Every endpoint in the API reference is a tool, except those listed in permissions.

Fetching argument shapes

A tool definition carries only its method, path and a one-line summary. Its argument schema is fetched on demand, which keeps the tool list small enough to load:

Tool	Returns
`describe_function`	One tool’s full description and argument schema, by tool name. Call it before using a tool for the first time
`describe_schema`	One of the five large request types below, by name

These two are the only tools whose arguments are inline; each takes a single name string. The same documents are served over HTTP at GET /v1/schemas/functions/{name} and GET /v1/schemas/{name} — see schemas.

The five deferred types

Inside a function’s argument schema, these types appear as a placeholder whose description names the document to fetch, for example "Full shape: describe_schema('AgentConfig')."

Name	What it is	Used by
`AgentConfig`	A whole agent definition	`create_agent`; inline `agent` on calls, chats, batches and web-call tokens
`AgentOverride`	`AgentConfig` with every field optional	`update_agent`; `agent_override` on calls, chats, batches and tokens
`AgentTeam`	Several agents on one call	`agent_team` on calls, chats, batches and tokens
`TaskConfig`	An agent task definition	`create_task`, `update_task`
`ToolOperations`	A tool’s operation tree	`create_tool`, `patch_tool`, and an inline tool inside `AgentConfig`

The documents nest: AgentTeam defers to AgentConfig and AgentOverride, and AgentConfig defers an inline tool’s operations to ToolOperations.

A placeholder is not a shape. Fetch the document before writing into that argument. A config written from memory is refused field by field, or worse, validates with a field that means something else.

Request validation is done by the API, not the MCP server, and always uses the full types.

Permissions

Roles, annotations, and what is not exposed.

Recipes

Prompts that use these tools end to end.

​Arguments mirror the HTTP call

​Names

​Fetching argument shapes

​The five deferred types

​Next

Permissions

Recipes

Arguments mirror the HTTP call

Names

Fetching argument shapes

The five deferred types

Next