honeybook-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| use_magic_linkA | Capture a HoneyBook client-portal session via the ContextMint Bridge browser extension. Prerequisites: install the ContextMint Bridge extension in Chrome (Safari isn't available yet), then open the vendor's magic-link URL in that browser so you're signed into their portal and leave that tab open. This tool then snapshots the auth fields out of the page's localStorage["HONEYBOOK_REACT_CURR_USER"] into ~/.honeybook-mcp/sessions.json. The tab only needs to be open and signed in — nothing is sniffed off a live request, so it does not matter whether the page is idle. All other tools use the most-recently-activated session by default. The magic_link_url arg is used only to derive the portalOrigin (cache key) — the tool does NOT open or navigate to it. For a QUESTIONNAIRE link (https://.hbportal.co/flow/?hash=…) use |
| list_active_sessionsA | List the HoneyBook credentials currently active in this MCP, split by kind: |
| use_flow_linkA | Capture a HoneyBook QUESTIONNAIRE (flow) credential via the ContextMint Bridge browser extension. Use this for a link shaped https://.hbportal.co/flow/?hash=… — for a client-portal link (/app/link/resolve/…) use |
| get_flowA | Read a HoneyBook questionnaire (flow) — its pages, questions and any answers already submitted — using a credential captured by |
| list_workspace_filesB | List all files a vendor has shared with you (contracts, invoices, brochures, proposals). Optionally filter by file_type. |
| get_workspace_fileA | Get detail for one workspace file. Returns a compact summary by default (metadata, vendor, event, pricing totals, payment schedule, agreement presence). Use |
| get_workspaceB | Get full detail for a workspace (vendor project). Includes status flags like has_sent_files, has_signed_files, has_paid_payments. |
| list_payment_methodsA | List saved payment methods for your client account with a vendor: id, type, brand, last 4, expiry and whether it is the default. Empty array if none are saved. view="raw" returns the untrimmed records (billing name/address and Stripe references). |
| sign_contractA | Sign a contract you received from a vendor. In v1 this returns a deep link to the HoneyBook portal instead of signing headlessly. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| pay_invoiceA | Pay an invoice from a vendor. In v1 this returns a deep link to the HoneyBook portal instead of paying headlessly. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). |
| list_projectsA | List your projects with a vendor (HoneyBook calls them events): name, date, booked flag and the workspace_id that every other workspace tool takes. This is the portal's project switcher. |
| get_projectA | Project details — the portal's Overview "Project details" card plus the people on it: name, date, time, timezone, location, guest count, custom fields, cover image, and each participant's name / email / phone / role. view="raw" returns the untrimmed response (large: it embeds the vendor's account). |
| list_messagesA | List the messages (and optionally the activity log) in a workspace — the portal's Activity tab. Returns compact cards (sender, subject, preview, seen state, attachments), newest first; call get_message for a full body. Reading does NOT mark anything as seen. |
| get_messageA | Read one message in full: body (plain text by default, or the original HTML), sender, recipients, attachments and per-recipient delivery status. |
| send_messageA | Send a message to the vendor (and the other members of the workspace) through the HoneyBook portal, exactly as the Activity tab composer does. HoneyBook emails it to every recipient. Pass reply_to_message_id to reply in-thread (the subject is inherited). Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). If HoneyBook has not finished sending within about a minute the result has status "pending" and a task_id: the message may still be delivered, so check list_messages before resending. |
| mark_messages_seenA | Mark feed items as seen (what the portal does when you open the Activity tab). list_messages and get_message never do this on their own. |
| list_meetingsA | Meetings the vendor has scheduled in a workspace (consultations, Zoom calls, walkthroughs): title, start/end, timezone, join link and password. Derived from the workspace feed, so a rescheduled meeting shows its latest time. Sorted by start. |
| list_tasksA | Tasks the vendor has assigned to you in a workspace — the portal's Tasks tab — with the today / this week / overdue / completed counts and any task groups. Sorted by due date. |
| list_notesB | Notes the vendor has shared with you in a workspace (meeting notes, AI recaps) — the portal's Notes tab. |
| list_attachmentsA | Loose images, files and bookmarks shared in a workspace — the portal's Files tab, minus the contracts/invoices/proposals that list_workspace_files covers. |
| list_paymentsA | Payment schedule for a workspace — the portal's Payments tab: each file's payments with amount, due date, paid/pending state, how it was paid and the invoice number, plus paid/unpaid totals per currency. To pay one, use pay_invoice. |
| honeybook_healthcheckA | Resolves the credential the way real tools do, then makes one authenticated request to api.honeybook.com. Reports which source supplied the credential, whether api.honeybook.com accepted it, the round-trip time, and a plain-English hint distinguishing 'no credential' from 'credential rejected' from 'a api.honeybook.com-side problem'. Read-only; never returns the credential itself. Call this when a real tool fails and you want to know which hop broke. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 22 tools
Nearly every tool targets a distinct resource plus action, and the descriptions proactively disambiguate the tricky pairs (list_attachments vs list_workspace_files, use_magic_link vs use_flow_link, list_payments vs list_payment_methods). The one soft spot is the workspace vs project duality (get_workspace/list_projects/get_project), where the relationship could momentarily confuse an agent, but the descriptions clarify it.
The set is overwhelmingly consistent snake_case verb_noun (list_notes, get_workspace_file, send_message, mark_messages_seen). Minor deviations are honeybook_healthcheck (noun_noun) and the use_*_link auth tools, but these remain readable and predictable.
22 tools sits in the heavier band, but the domain is genuinely broad (auth sessions, flows, workspaces, files, payments, messages, meetings, tasks, notes) and each tool maps to a real capability. Nothing looks redundant or padded, so the count is justified though on the larger side.
Strong read coverage across workspaces, files, projects, messages, payments, meetings, notes and tasks, plus messaging/sign/pay write paths. Gaps are minor: pay_invoice and sign_contract are deep-link stubs rather than headless actions, there are no per-item getters for notes/attachments, tasks cannot be marked complete, and there is no cross-workspace search.