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_filesA | List all files a vendor has shared with you (contracts, invoices, brochures, proposals). Optionally filter by file_type. Follows every page; returns { files, complete } — complete:false means some files could not be fetched. Each file is a light summary row by default (id, title, type, status, sent date, workspace, payment/acceptance flags); call get_workspace_file with its _id for pricing, contract or payments, or pass view="all" for every pruned file object (large). |
| 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 — it signs nothing itself; the user signs in their browser. It still asks the user to confirm before handing over the link: 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 — it moves no money itself; the user pays in their browser. It still asks the user to confirm before handing over the link: 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; if it did not answer the send request at all the status is "unknown". Either way 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
Most tools target a distinct resource+action (get_workspace, list_messages, pay_invoice, sign_contract), and descriptions carefully separate the portal-session vs flow-credential families. However, there is real conceptual overlap between get_workspace (a 'vendor project') and get_project (the portal's Overview), and between list_workspace_files and list_attachments, which could cause occasional misselection.
Nearly the entire set follows a snake_case verb_noun convention (list_projects, get_message, send_message, sign_contract, pay_invoice, mark_messages_seen). The only deviation is honeybook_healthcheck, which uses a server-prefixed style rather than a verb_noun form.
22 tools is on the heavy side but justified by a genuinely broad client-portal domain spanning credentials, projects, workspaces, files, payments, messages, tasks, notes and meetings. No tool appears obviously redundant.
Read coverage is thorough across the portal, but write/action coverage is thin: clients cannot submit questionnaire answers (get_flow only reads them), upload or share files, or perform most mutating actions beyond messaging, signing and paying. These gaps could cause dead ends for common client workflows.