Every tool on the server is one API endpoint. Its name is the endpoint’s operation name, its description is the endpoint’s own documentation, and its arguments mirror the HTTP call: path and query parameters at the top level, the request body under body. Nothing is rewritten in between, so what your agent learns here is true of the API and of the SDKs.

​
Arguments mirror the HTTP call

Take assign_phone_number. The server describes it to your client as POST /v1/telephony/phone-numbers/{number_id}/assign, and its input schema has two properties: number_id, the path parameter, and body, which keeps the endpoint’s own request shape.
Arguments
That is exactly this call:
Keeping the body nested is what makes that mapping unambiguous: a path parameter can never collide with a body field of the same name. Query parameters follow the same rule — list_calls takes agent_id, status, batch_id, start, end, limit and offset at the top level, because that is where the URL carries them. Every tool’s argument schema is closed at the top level — additionalProperties: false — so a client that validates arguments catches an invented path or query parameter before it is sent. What goes under body is validated by the API itself, which answers with one error envelope naming each field that failed.

​
Names

A tool name is the API’s operation name, and the SDKs derive their method names from the same map: So a session that starts in your terminal and ends in your application code uses one vocabulary throughout.

​
Deferred schemas

Five request types are whole product surfaces: an agent’s config, its all-optional override twin, a team of agents, a task’s config, and a tool’s operation tree. MCP gives no way for tools to share definitions — every tool’s input schema has to stand alone — so a type that appears on six endpoints would be carried six times. Inlined, those five accounted for more of the tool surface than everything else on the server put together, and the result did not fit in a 200k-context client at all. They are deferred instead of duplicated. Wherever one appears as a property, the tool schema carries a placeholder and a pointer, and describe_schema serves the real document on demand. The create_agent schema, in full, is:
The five:
An argument whose description ends in describe_schema('X') carries a placeholder, not a shape. It has to be fetched before anything is written into it, never reconstructed from memory. A config assembled from a model’s recollection of what an agent looks like is refused field by field on the first write, and that is the good case — the bad one is a field that validates and means something else.
These documents compose, so one you fetch may itself defer to another: AgentTeam is small because the two documents it is built from defer out of it exactly as they do out of a tool, and AgentConfig defers its inline tool’s operations to ToolOperations. Fetch what you need, in the order you need it. The same documents are served over HTTP at GET /v1/schemas/{name}; see schemas.

​
Read-only and destructive

Every tool is annotated so a client can tell a read from a write before it runs one: A client that renders approval prompts uses these to decide what to wave through. readOnlyHint is derived from the HTTP method, not from what the operation feels like, so read it as “this cannot change anything”, not as “this is free”: get_call is read-only and returns a transcript, while run_tool is a POST that calls your endpoints for real. Permissions has the list worth approving by hand.

​
Everything available

123 operations, by area.

​
What is not a tool, and what to use instead

Server-sent event streams are not tool-shaped: a tool call returns once, and a stream stays open for minutes. Each one has a polling equivalent, so nothing on the API is unreachable from here. Three more things are absent for their own reasons:
  • The CoPilots’ chat endpoints. The agent, tool, task and knowledge CoPilots each have a stream of their own. They are not exposed, because an AI builder must not drive another AI builder — your client is the builder here.
  • A call’s recording file. GET /v1/calls/{session_id}/recording is a redirect to an audio blob, which a tool call cannot hand to a model. get_call reports recording.state, which is the part an agent can reason about; play or download the file from the dashboard. See recordings.
  • Inbound provider and carrier webhooks. Those are callbacks into Talqing, not operations you call.
Four further areas are out of reach on purpose rather than for shape — permissions covers those, with the reasoning for each.

​
Next

Permissions

Roles, what the server cannot do, and what to approve by hand.

Recipes

Prompts that use these operations end to end.