Skip to main content
Glama
Sign In
chrischall

honeybook-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

list_payment_methods

Read-only

List saved payment methods for a client account with a vendor: card ID, type, brand, last 4, expiry, and default status. Use view='raw' for full billing details.

Instructions

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).

Input Schema

NameRequiredDescriptionDefault
viewNoResponse shape: "compact" (default) drops fields the response already carries elsewhere; "raw" returns the upstream payload unprojected. compact returns only the card-on-file fields; "raw" returns the untrimmed records, including billing name/address and Stripe references.
originNoPortal origin (e.g. https://<vendor>.hbportal.co). Optional when only one session is active.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.1
    • 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 only the card-on-file fields; \"raw\" returns the untrimmed records, including billing name/address and Stripe references.",
+  "enum": [
+    "compact",
+    "raw"
+  ],
+  "type": "string"
+}
  2. 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"
  3. First observedv0.3.1

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuine behavioral context beyond that: the empty-array outcome when nothing is saved, and that view="raw" exposes untrimmed records including billing name/address and Stripe references, which is sensitive-data disclosure the annotations do not convey.

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?

Three tight sentences, front-loaded with purpose, then edge case, then the view flag. The raw-view clause largely duplicates the schema's own view description, which is the only minor waste.

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 usefully enumerates the returned fields and the empty-result case, and annotations cover the read-only profile. It leaves the origin parameter's session behavior to the schema, which is acceptable given the schema documents it fully.

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 view enum is fully documented in the schema, including the compact/raw distinction. The description restates the raw-view behavior but adds no syntax, defaults, or constraints the schema lacks, so the baseline of 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 and resource ('List saved payment methods') scoped to a client account with a vendor, and enumerates the returned fields. This clearly separates it from the sibling list_payments, which deals with payments rather than stored instruments.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: an agent can infer it retrieves saved cards, but there is no explicit when-to-use, no exclusion, and no pointer to list_payments or other siblings for related data. The empty-array note is the only boundary condition given.

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