HoneyBook

Used by the HoneyBook approval card when the member approves. Runs the change they reviewed, exactly as shown.

approve_action

Puts a change that take_action paused for approval in front of the member, as a card they approve or decline. Call it only when take_action says a change needs approval, with the proposalId it gave. Nothing runs until the member approves in the card.

show_approval

Used by the HoneyBook approval card when the member declines. Nothing runs.

decline_action

Look up how to carry out a task in HoneyBook with these tools — how HoneyBook structures the data behind a request and which operation applies (e.g. "who hasn't paid me", "is the contract signed", "leads vs booked"). Returns the relevant how-to guide(s); its guidance precedes find_action and take_action.

get_guidance

Look up how to do something in HoneyBook: search by keyword to get the exact function to call, its inputs, and what it returns. Use before take_action; do not guess function names — a wrong one will not run.

find_action

The read-only form of take_action: run TypeScript that looks things up in HoneyBook. It does the same reads as take_action, but any attempt to make a change is blocked — the safe choice when a request only needs to look something up. To make a change, use take_action. A ready `httpClient` is already in scope — do not create it. Work goes through a domain adapter: import the adapter `find_action` names, construct it with `httpClient`, and call its method with named args (`{ id }` for a path id, `{ params }` for filters/query, `{ data }` for a payload): import { ContactsAdapter } from '@honeybook/sdk/contacts'; const contacts = new ContactsAdapter(httpClient); const page = await contacts.listContacts({ params: { query: 'jane' } }); console.log(page.data); console.log is how you return data to the caller — your code runs as an ES module, not a function body, so a top-level `return` is a syntax error and the whole run fails before anything executes. Methods return the result directly and throw on failure — there is no `{ data, error }` wrapper; a list comes back once-wrapped as `{ data, pagination }`. Keep a whole job in one call — a value from one step (like a returned id) feeds the next. That includes looping: when a job spans many records, list them and iterate in the SAME call — `for (const r of page.data) { … }`, or `await Promise.all(page.data.map(r => …))` for independent reads. One call is one sandbox, so splitting a 20-record job across 20 calls is 20 sandboxes and will be refused partway through, leaving you a partial answer that looks complete. Before looping to add something up, check `find_action` for an operation that returns the total directly — several exist, and one call beats reading every record. Passing readOnly to `find_action` narrows its results to the operations that only read.

take_action_read_only

Used by the HoneyBook approval card. Opens a pending approval request in this card, or reports where it stands.

open_approval

Searches HoneyBook's official Help Center — the same articles a HoneyBook user reads — and returns content explaining how a product feature works, step-by-step how-to instructions, and troubleshooting (e.g. "how do I send an invoice", "what is a payment schedule").

search_help_center

Send a short report to the team that builds the HoneyBook MCP connector, so a problem gets fixed. Use it when: - the user needed something the HoneyBook MCP connector can't do — after you've told them it isn't possible; - guidance or an operation lookup was missing, wrong or misleading and it cost you attempts, or an operation doesn't do what its description says; - the user asks you to pass something on to HoneyBook. Don't send a report just because a tool returned an error — errors are already tracked. Nor for a mistake you made and fixed (a typo in your code, a retry that worked), the user's own mistakes, or the same problem twice. One call per distinct problem. Describe the problem, not the people or the conversation: leave out names, emails, phone numbers, addresses and amounts belonging to the user or their clients (write "a client", "an invoice"), never include credentials, and don't paste the conversation. It changes nothing in the user's account.

send_feedback

Run TypeScript to do anything in HoneyBook — look things up and make changes (create, update, delete), including a flow that reads first and then writes off what it found. A ready `httpClient` is already in scope — do not create it. Work goes through a domain adapter: import the adapter `find_action` names, construct it with `httpClient`, and call its method with named args (`{ id }` for a path id, `{ params }` for filters/query, `{ data }` for a payload): import { ContactsAdapter } from '@honeybook/sdk/contacts'; const contacts = new ContactsAdapter(httpClient); const page = await contacts.listContacts({ params: { query: 'jane' } }); console.log(page.data); console.log is how you return data to the caller — your code runs as an ES module, not a function body, so a top-level `return` is a syntax error and the whole run fails before anything executes. Methods return the result directly and throw on failure — there is no `{ data, error }` wrapper; a list comes back once-wrapped as `{ data, pagination }`. Keep a whole job in one call — a value from one step (like a returned id) feeds the next. That includes looping: when a job spans many records, list them and iterate in the SAME call — `for (const r of page.data) { … }`, or `await Promise.all(page.data.map(r => …))` for independent reads. One call is one sandbox, so splitting a 20-record job across 20 calls is 20 sandboxes and will be refused partway through, leaving you a partial answer that looks complete. Before looping to add something up, check `find_action` for an operation that returns the total directly — several exist, and one call beats reading every record. Changes use the same adapter pattern, e.g. `await contacts.createContact({ data: { email: '[email protected]' } })`. The result reports what was committed (with returned IDs) and anything that failed, and says what to do next — read it before replying. When a request only looks something up and changes nothing, take_action_read_only does the same reads but cannot make a change — prefer it there.

take_action