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 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
Section titled “Keep going”- The confirmation gate on writes — what every “Type: Write” tool requires before it calls the API.
- Connect your assistant — per-client configuration blocks.
- REST reference, under the API section — the full detail for every operation (parameters, body, response).