Skip to main content
Glama
chrischall

honeybook-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

use_flow_link

Idempotent

Capture a HoneyBook questionnaire (flow) credential from a rendered /flow link via the ContextMint Bridge extension; the saved credential grants access only to that questionnaire.

Instructions

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 use_magic_link instead. Prerequisites: install the ContextMint Bridge extension, open the questionnaire link in that browser and let the page render, then run this tool. It snapshots localStorage["HONEYBOOK_REACT_WEAK_AUTH_"] into ~/.honeybook-mcp/flows.json. A flow credential is HoneyBook's 'weak auth': it is scoped to that ONE questionnaire and cannot read portal workspaces, files, invoices or payment methods. Because the storage key contains the flow id, the extension asks you to re-approve the scope once per new questionnaire.

Input Schema

NameRequiredDescriptionDefault
flow_link_urlYesQuestionnaire link, e.g. https://<vendor>.hbportal.co/flow/<flowId>?hash=…&userId=… Only the /flow/<flowId> segment is required: the credential is read out of the open page's localStorage, so the rewritten step URL (/flow/<flowId>/1-Questions) works too. The URL's ?hash= is used only as a fallback when the page stored none, so prefer the original email link if the capture reports no hash.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Addedv0.9.0

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), and the description adds substantial context beyond them: it writes to ~/.honeybook-mcp/flows.json, the credential is HoneyBook 'weak auth' limited to one questionnaire, it cannot read portal workspaces/files/invoices/payment methods, and scope must be re-approved once per new questionnaire.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose, then routing to the sibling, then prerequisites, then behavioral scope — a logical order with little waste. Slightly long and dense, but nearly every sentence (routing, prerequisites, scoping) carries load-bearing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description covers prerequisites, the exact side effect and destination file, credential scope limits, and the re-approval behavior. An agent has everything needed to invoke it correctly and predict the outcome.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single parameter already documents the URL shape, the /flow/<flowId> segment requirement, and the ?hash= fallback. The description largely restates the same URL constraints, so it adds little parameter-specific meaning beyond the schema. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (capture) plus resource (HoneyBook QUESTIONNAIRE flow credential) and immediately names the sibling it is not: for client-portal /app/link/resolve/… links use `use_magic_link` instead. An agent can distinguish it from use_magic_link without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use based on URL shape (https://<vendor>.hbportal.co/flow/<flowId>?hash=…), an explicit when-not with the named alternative (use_magic_link for portal links), and concrete prerequisites (install extension, open link, let page render before running).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools