Every tool the MCP server exposes corresponds to **exactly one** public API operation (`/public/v1`) — the server generates them at startup by reading its OpenAPI definition, there are no hand-written tools and no list anyone could forget to update (`SPEC_MCP_PROPIO.md` §2). This table is generated the same way, from the same document — if an endpoint appears or disappears from the API, the table changes on its own on the next build. The tools your MCP client sees at any given moment are only the ones your key can use: the server calls `GET /public/v1/me` and filters by your key's effective scopes, the same list from the **[Authentication](/api/authentication/)** guide. `aymar_status` isn't in the table because it doesn't come from any cataloged endpoint — it's the MCP server's own tool for checking your tenant, plan and effective scopes, always visible. | Resource | Tool | Operation | Required permission | Type | | --- | --- | --- | --- | --- | | Leads | `aymar_leads_create` | `POST /public/v1/leads` | `tenant:leads.manage` | Write | | Leads | `aymar_leads_get` | `GET /public/v1/leads/{lead_id}` | `tenant:leads.read` | Read | | Leads | `aymar_leads_list` | `GET /public/v1/leads` | `tenant:leads.read` | Read | | Leads | `aymar_leads_update` | `PATCH /public/v1/leads/{lead_id}` | `tenant:leads.manage` | Write | | Contacts | `aymar_contacts_create` | `POST /public/v1/contacts` | `tenant:contacts.manage` | Write | | Contacts | `aymar_contacts_get` | `GET /public/v1/contacts/{contact_id}` | `tenant:contacts.read` | Read | | Contacts | `aymar_contacts_list` | `GET /public/v1/contacts` | `tenant:contacts.read` | Read | | Contacts | `aymar_contacts_update` | `PATCH /public/v1/contacts/{contact_id}` | `tenant:contacts.manage` | Write | | Conversations | `aymar_conversations_get` | `GET /public/v1/conversations/{conversation_id}` | `tenant:conversations.read` | Read | | Conversations | `aymar_conversations_list` | `GET /public/v1/conversations` | `tenant:conversations.read` | Read | | Conversations | `aymar_conversations_list_messages` | `GET /public/v1/conversations/{conversation_id}/messages` | `tenant:conversations.read` | Read | | Conversations | `aymar_conversations_send_message` | `POST /public/v1/conversations/{conversation_id}/messages` | `tenant:conversations.manage` | Write | | Conversations | `aymar_conversations_start` | `POST /public/v1/conversations/start` | `tenant:conversations.manage` | Write | | Appointments | `aymar_appointments_create` | `POST /public/v1/appointments` | `tenant:appointments.manage` | Write | | Appointments | `aymar_appointments_get` | `GET /public/v1/appointments/{appointment_id}` | `tenant:appointments.read` | Read | | Appointments | `aymar_appointments_list` | `GET /public/v1/appointments` | `tenant:appointments.read` | Read | | Appointments | `aymar_appointments_update` | `PATCH /public/v1/appointments/{appointment_id}` | `tenant:appointments.manage` | Write | | Appointments | `aymar_availability_list` | `GET /public/v1/availability` | `tenant:appointments.read` | Read | | Tickets | `aymar_tickets_add_comment` | `POST /public/v1/tickets/{ticket_id}/comments` | `tenant:tickets.manage` | Write | | Tickets | `aymar_tickets_create` | `POST /public/v1/tickets` | `tenant:tickets.manage` | Write | | Tickets | `aymar_tickets_get` | `GET /public/v1/tickets/{ticket_id}` | `tenant:tickets.read` | Read | | Tickets | `aymar_tickets_list` | `GET /public/v1/tickets` | `tenant:tickets.read` | Read | | Tickets | `aymar_tickets_update` | `PATCH /public/v1/tickets/{ticket_id}` | `tenant:tickets.manage` | Write | ## Keep going - **[The confirmation gate on writes](/mcp/confirm/)** — what every "Type: Write" tool requires before it calls the API. - **[Connect your assistant](/mcp/connect/)** — per-client configuration blocks. - **REST reference**, under the **API** section — the full detail for every operation (parameters, body, response).