Avochato MCP integration for AI agents.
Connect AI agents to Avochato through 7 structured actions, including get contacts, send message, and get current identity. Review authentication, inputs, wo…
- ACTION CONTRACTS
- 7
- AUTHENTICATION
- Custom credentials
- SOURCE STATUS
- Provider-backed
CATALOG SOURCE REVIEWED AUGUST 23, 2026 / ACTION NAMES AND SCHEMAS DERIVED FROM WORKING MACHINES PROVIDER SOURCE
CAPABILITY PROFILE
What the Avochato integration exposes
The Avochato Agent App exposes 7 provider-backed actions for communication and marketing work. Its current contract lets an authorized agent retrieve one or more avochato contacts by their identifiers, send a text message to an avochato contact phone number, and retrieve the account and user associated with the configured avochato api tokens. These operations are called through Working Machines as typed capabilities rather than through browser navigation or copied UI steps.
A connection uses Custom credentials. Before execution, the agent can inspect the selected action, its required fields, declared scopes, and expected output contract. Provider credentials remain inside the Working Machines runtime; the calling agent receives the capability and its structured result, not the underlying secret.
For reliable operation, start with the narrowest action that satisfies the task, resolve stable provider identifiers before changing state, and validate the returned object or status after execution. Availability still depends on the connected Avochato account, granted provider permissions, workspace policy, region, plan, and upstream API behavior.
VERIFIED ACTION SAMPLE
Real Avochato capabilities.
Showing 7 of 7 actions. Risk labels are conservative signals based on operation names, not substitutes for provider documentation or runtime policy.
get_contactsREADRetrieve one or more Avochato contacts by their identifiers.
INPUTS: ids / page
send_messageWRITESend a text message to an Avochato contact phone number.
INPUTS: phone / message / from / markAddressed / tags
get_current_identityREADRetrieve the account and user associated with the configured Avochato API tokens.
get_messageREADRetrieve one Avochato message by its Event ID.
INPUTS: eventId
list_contactsREADList contacts in the Avochato inbox with cursor-style pagination.
INPUTS: afterPage / limit
list_messagesREADList or search messages in the Avochato inbox.
INPUTS: query / page / direction / status / from
upsert_contactWRITECreate or update an Avochato contact, matched by phone number.
INPUTS: phone / name / email / otherPhone / company
INPUT CONTRACTS
Know what the action needs before it runs.
get_contacts
idsREQUIRED- One or more Avochato contact identifiers.
pageOPTIONAL- Page number to request.
send_message
phoneREQUIRED- Recipient phone number.
messageREQUIRED- Text to send to the recipient.
fromOPTIONAL- Avochato E.164 number to send from.
markAddressedOPTIONAL- Whether to mark the conversation as addressed.
tagsOPTIONAL- Comma-separated tags to apply to the contact.
get_message
eventIdOPTIONAL- Message Event ID returned as event_id by Avochato.
list_contacts
afterPageOPTIONAL- Opaque nextPage value returned by a previous list_contacts call.
limitOPTIONAL- Number of contacts to return, from 1 through 100.
PROVIDER-SPECIFIC WORKFLOWS
Jobs this Agent App can support
Inspect Get Contacts
Retrieve one or more Avochato contacts by their identifiers. Use this as a bounded discovery step, retain the returned identifier, and avoid expanding the read beyond the task's stated scope.
get_contactsControl Send Message
Send a text message to an Avochato contact phone number. Resolve the target first, present material changes for confirmation, and make retries idempotent where the provider supports it.
send_messageVerify with Get Current Identity
Retrieve the account and user associated with the configured Avochato API tokens. Compare the returned provider state with the intended outcome and preserve stable IDs or canonical links in the run record.
get_current_identitySAFETY BOUNDARY
Operate Avochato with explicit limits
- Authorize Avochato with Custom credentials and grant only the provider access required by the selected actions.
- 2 actions are change-capable by name. Confirm the target identity and material parameters before allowing a write.
- Do not infer permission from catalog visibility. Workspace policy, connection identity, and upstream authorization still govern execution.
- No provider scope string is declared on the sampled actions. Verify the connected account's actual permissions in Avochato rather than assuming unrestricted access.
- After a call, inspect the structured result and execution record before reporting that the Avochato task completed successfully.
CONNECTION MODEL
Custom credentials
Avochato uses Custom credentials. Connection requirements and availability are determined by the provider and the Working Machines deployment.
Working Machines stores provider credentials behind the execution boundary. An agent can use an authorized connection identity, but catalog discovery alone does not reveal OAuth tokens, API keys, or provider secrets.
- READ SIGNALS
- 5
- WRITE SIGNALS
- 2
- HIGH IMPACT
- 0
- REVIEW SIGNALS
- 0
EVIDENCE AND AVAILABILITY
Provider reference
Action names, input fields, authentication types, and counts on this page are generated from the Working Machines provider catalog. Provider behavior, quotas, object semantics, account eligibility, and regional availability remain governed by Avochato.