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 fetchproxy 0.3.0 browser extension. Prerequisites: install the fetchproxy extension in Chrome/Safari, 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 fetchproxy 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. Empty array if none are saved. |
| 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. Requires confirm:true. |
| pay_invoiceA | Pay an invoice from a vendor. In v1 this returns a deep link to the HoneyBook portal instead of paying headlessly. Requires confirm:true. |
| 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). Requires confirm:true. |
| 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 clearly target a distinct resource and action, with list_/get_/use_ prefixes separating concerns. A few boundaries require careful reading—get_project vs get_workspace overlap, and list_workspace_files vs list_attachments split by file type—but the descriptions provide enough differentiation.
The naming is largely consistent: list_* for collections, get_* for single resources, and use_* for credential capture. The main deviation is honeybook_healthcheck, which breaks the verb_noun pattern, and mark_messages_seen is slightly awkward but still readable.
At 22 tools, the set is on the heavy side and fits the '16-25 feels heavy' band. The broad domain justifies many of them, but the numerous narrow list_* tools create a large surface that an agent must navigate.
The surface covers core client-portal workflows well: authentication, projects, files, messages, tasks, meetings, notes, attachments, payments, contracts, and invoices. Minor gaps exist—no attachment detail retrieval, no task/meeting action tools, and no payment method management—but agents can work around these.