Skip to main content
Glama
oliverames

MCP Server for Wave

by oliverames
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Wave: List Estimates

wave_list_estimates
Read-onlyIdempotent

List Wave estimates (quotes) with filters by status, customer, date range, amount, or number. Retrieve paginated results for review or export.

Instructions

List estimates (quotes), filtered by status, customer, or date range.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo1-based page number for offset pagination.
sortNoA single value such as "ESTIMATE_DATE_DESC" or "TOTAL_DESC". Defaults to ESTIMATE_DATE_DESC.
statusNoDRAFT, SENT, VIEWED, ACCEPTED, APPROVED, CONVERTED, EXPIRED, REJECTED, ACTIVE, PAID, PARTIAL, UNPAID.
currencyNoCurrency code, e.g. "USD".
fetch_allNoWalk every page instead of returning just one. Slower, but complete.
page_sizeNoRecords per page (1-200).
amount_dueNoExact outstanding amount match.
business_idNoBusiness to operate on: the base64 id from wave_list_businesses (a bare business UUID is also accepted). Defaults to the business set by wave_set_default_business. When calls may be minutes apart, pass it on every call.
customer_idNoOnly estimates for this customer.
modified_afterNoISO 8601 timestamp; only estimates changed after it.
estimate_numberNoExact estimate number match.
modified_beforeNoISO 8601 timestamp; only estimates changed before it.
response_formatNoOutput format: "markdown" for a compact human-readable summary, "json" for the complete record.markdown
estimate_date_endNoLatest estimate date, YYYY-MM-DD.
estimate_date_startNoEarliest estimate date, YYYY-MM-DD.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.8
    • changedInput schema / properties / business_id / description
      Previous value: -"Business to operate on. Defaults to the session business set by wave_set_default_business."New value: +"Business to operate on: the base64 id from wave_list_businesses (a bare business UUID is also accepted). Defaults to the business set by wave_set_default_business. When calls may be minutes apart, pass it on every call."
  2. First observedv1.0.2

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the filtering capability; it does not mention pagination behavior, fetch_all implications, or the business_id default/fallback, so it adds modest context beyond annotations but not rich behavioral detail.

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

Conciseness5/5

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

One front-loaded sentence with no filler; it names the operation and key filter categories immediately. Given the schema carries parameter detail, this is appropriately sized.

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

Completeness3/5

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

For a 15-parameter tool with no output schema, the description is minimally viable: it identifies the operation and main filter dimensions, while the schema covers parameter specifics and annotations cover read-only/idempotent behavior. It lacks a pointer to the singular wave_get_estimate for detail lookup and does not characterize response_format or pagination behavior, though those are recoverable from schema defaults.

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%, with every parameter, default, and enum already documented in the schema. The description's mention of filters by status, customer, or date range mirrors a subset of those parameter descriptions rather than adding new meaning.

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?

States a specific verb ('List') and resource ('estimates'), and clarifies the synonym 'quotes' plus common filters. It is clear but does not explicitly differentiate from sibling wave_get_estimate or the filtering scope of wave_list_invoices, so it misses the top tier for sibling distinction.

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

Usage Guidelines2/5

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

The description implies a list/query use case but gives no when-to-use guidance, exclusions, or alternatives. Siblings like wave_get_estimate for single-record detail or wave_set_default_business for business context are not mentioned, leaving tool routing to inference.

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