Reading tools are list_* — one per collection, listed on the overview. They take the same arguments, because they are the same API endpoints underneath:

Argument	Meaning
`limit`	Records per page, 1–50, default 20.
`offset`	Records to skip.
`search`	Free-text match over the record's main fields.
`sortBy`, `sortOrder`	Field and direction; an unknown field falls back to newest first.
`createdAfter`, `createdBefore`, `updatedAfter`	ISO 8601 timestamps.
`locationId`	Which location to read, on the tools that belong to one.
`companyId`	Which company, when the connection covers more than one. Absent otherwise.

A list tool also takes the filters its endpoint documents in the API reference — direction, unread and mailbox on list_emails, status on list_support_conversations, type on list_notifications — as arguments of the same names. The reference page for the endpoint is the full list.

A few records get a get_* tool of their own, because an assistant reaches for them one at a time: get_email, get_email_thread, get_email_draft, get_support_conversation, get_build_session, get_conversation. Each takes the record's id and the endpoint's documented flags (includeHtml on a message, say). Everything else is read with get_api_resource.

A few reads hang off a record and take two ids, so they have a tool of their own too: list_conversation_messages and get_message_thread (see Threads).

Two tools are not collections:

whoami — who the calls act as, the companies the connection covers, and the tools each unlocks. Worth calling first in a conversation. It is built by the same function as tools/list, so in the full list the two always agree; a client showing fewer tools is deferring part of a large catalog on its own side, which Claude Code does. In search mode it counts the tools by domain instead.
get_api_resource — one record, or any API path with no tool of its own: { "path": "customers/<id>" }, { "path": "settings/company" }. Pass fields to keep only what you need (["subject", "user.fullname"]), which is how a large record stays inside one answer; without it a record over the size limit is cut off with a note saying so. It goes through the same scope checks as everything else, so it can't reach past what you granted. One read is held back whatever you grant: a Vault credential's secret never comes into a conversation.

Results come back summarized — the fields that identify a record, not every column — with a line above the data saying how many of how many you're looking at and how to page further. Use get_api_resource when you need a full record.

Writes

Every create, update, delete and action the API implements is a tool of its own — create_customer, update_ticket, void_invoice, send_invoice_email — taking that endpoint's fields as arguments, plus locationId (filled in when the company has one location) and companyId (when the connection covers several). Ids in a path accept only letters, digits, _ and -.

A write appears only where the connection was granted its scope. :read never unlocks one.
Deletes, voids, archives, cancellations and whole-set replacements are marked destructive; clients that honour the hint ask before running them.
Creating an invoice doesn't send it — send_invoice_email does.
Mail is never sent straight from a tool call. create_email_draft writes it into the person's Drafts, where they can read it in the console or through you, and send_email_draft — marked as reaching outside the company, so a client asks first — is what puts it in somebody's inbox.
There are no idempotency keys. If a create fails with a 5xx or times out, it may still have happened: read the collection back before trying again.