Skip to main content
Glama
chrischall

honeybook-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

get_flow

Read-only

Retrieve a HoneyBook questionnaire's pages, questions, and submitted answers using a captured flow credential. Defaults to the most recently captured flow.

Instructions

Read a HoneyBook questionnaire (flow) — its pages, questions and any answers already submitted — using a credential captured by use_flow_link. Requires a flow credential; a client-portal session will NOT work here, and vice versa. Defaults to the most recently captured flow. Makes two calls: the public /api/v2/flow//minimal for the vendor company id, then /api/v2/client/flow//active, passing that id as ?ctxc= when /minimal supplied one. A questionnaire larger than the default ceiling answers with its size and top-level keys instead; call again with view="raw" for the whole thing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
viewNoResponse shape: "compact" (default) drops fields the response already carries elsewhere; "raw" returns the upstream payload unprojected. compact returns the questionnaire unless it exceeds a byte ceiling, in which case it answers with its size and top-level keys instead; "raw" returns the full payload however large (may exceed MCP size limits).
flow_idNoFlow id to read. Omit to use the most recently captured flow credential. Run `list_active_sessions` to see the active flow ids.

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. Changed2 schema fields changedv0.10.1
    • removedInput schema / properties / section
      Removed value: -{
-  "description": "Default \"summary\" returns the questionnaire unless it exceeds a byte ceiling, in which case it answers with its size and top-level keys instead. \"raw\" returns the full payload however large (may exceed MCP size limits).",
-  "enum": [
-    "summary",
-    "raw"
-  ],
-  "type": "string"
-}
    • addedInput schema / properties / view
      Added value: +{
+  "description": "Response shape: \"compact\" (default) drops fields the response already carries elsewhere; \"raw\" returns the upstream payload unprojected. compact returns the questionnaire unless it exceeds a byte ceiling, in which case it answers with its size and top-level keys instead; \"raw\" returns the full payload however large (may exceed MCP size limits).",
+  "enum": [
+    "compact",
+    "raw"
+  ],
+  "type": "string"
+}
  3. Addedv0.9.0

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses significant internal behavior: it makes two API calls, how it passes a context parameter, and how it handles questionnaires exceeding a size ceiling (returns size and top-level keys, with raw view as a workaround). This is exceptionally transparent and adds value beyond the annotation.

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?

The description is dense but well-structured, front-loading the purpose and then adding credential requirements, default behavior, and edge cases. Each sentence contributes necessary information given the tool's complexity, though it is slightly longer than minimal.

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

Completeness4/5

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

With no output schema, the description covers the return value at a high level (pages, questions, answers) and explains the ceiling case. It also explains the two-call process and credential needs. The tool is simple to invoke (0 required params), and the description is sufficient for correct usage.

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%, so both parameters are already well documented. The description adds only marginal detail (e.g., the ceiling behavior for view='raw' is already in the schema). It does not substantially enhance parameter understanding beyond the schema, so the baseline 3 is appropriate.

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

Purpose4/5

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

The description clearly states the tool reads a HoneyBook questionnaire, listing its content (pages, questions, answers). It distinguishes itself by the credential type (flow credential vs client-portal session), but does not explicitly name a sibling tool, so it earns a 4 rather than a 5.

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

Usage Guidelines4/5

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

The description provides explicit guidance on when to use the tool: requires a flow credential and explicitly notes a client-portal session will NOT work. It also explains the default behavior (most recently captured flow) and suggests using list_active_sessions for flow ids, giving clear context without naming an alternative tool directly.

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