InvoiceVista Invoice Maker

by com.invoicevista

Overview Discussions Admin

Server Details

See revenue, unpaid invoices, open quotes and your product catalog for each of your businesses.

Ownership verified

Status: Healthy
Uptime: 99.6% over 40 days
Last Tested: 2026-11-06 20:56
Transport: Streamable HTTP · MCP 2025-11-25
URL
ChatGPT: InvoiceVista Invoice Maker
Claude: –

TDQS

A4.1/5.0

Scored 2026-11-06 11:55 across 14 tools

Disambiguation4/5

The four summary tools (revenue, receivables, quote pipeline, business overview) could superficially collide, but each description explicitly scopes the metrics and adds a 'Not for…' clause naming the sibling tool, so the boundaries are clear. The only mild overlap is between open_invoicevista and show_business_overview, both of which surface dashboard-like business browsing.

Naming Consistency4/5

Nearly all tools follow a clean snake_case verb_noun pattern (create_customer, get_revenue_summary, list_products, set_inventory_quantity), with verb choice carrying real meaning (get vs find vs list vs show). The lone deviation is open_invoicevista, which uses the product brand as its object rather than a resource noun.

Tool Count5/5

Fourteen tools is well within a comfortable range and each one maps to a distinct resource or report. Nothing feels padded, and the mix of customer mutations, catalog/stock reads, and financial summaries is proportionate to the server's scope.

Completeness2/5

Despite being an 'Invoice Maker', the surface has no create_invoice, no send_invoice, no record_payment and no quote creation; the descriptions explicitly defer those to the UI. Customer management is also partial (create/find/update but no delete, get-by-id, or full listing), and products/inventory are read-only except for one quantity setter.

Available Tools

14 tools

create_customerAdd a customerA

DestructiveIdempotent

Inspect

Use this when someone asks to add a new customer to a business, such as a client they are about to invoice. Returns the customer's id, name, business and language; the email, phone, tax id and address given are saved but never returned. Not for changing an existing customer.

Name	Required	Description
`name`	Yes	The customer's full or company name.
`email`	No	Email address their invoices go to.
`phone`	No	Mobile number, with the country code when known.
`taxId`	No	Tax or VAT number printed on their invoices.
`address`	No	Billing address.
`language`	No	Language for their invoices and messages, as a code such as en, it or pt-BR; the business language when absent.
`requestId`	Yes	A unique id for this customer, such as a UUID. A repeated call with the same requestId returns the first customer and adds no second one.
`businessId`	No	Business id: 24 lowercase hexadecimal characters; may be absent when the account has one business.
`legalEntity`	No	What kind of customer this is; a new customer is stored as a company when absent.

Output Schema

Name	Required	Description
`status`	Yes
`customer`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare write/idempotent/destructive/openWorld=false, so the description's real contribution is the data-fate disclosure: id, name, business and language come back, while email, phone, tax id and address are stored but never returned — a genuinely useful insight an agent cannot infer from the schema. It does not explain the destructiveHint=true implication (e.g. whether a created customer can be undone or removed), which is the one behavioral gap.

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?

Three tight sentences: when to use, what comes back and what does not, then the exclusion. The routing constraint is front-loaded and no sentence is filler.

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?

For a 9-parameter create tool with nested address, an enum, an output schema and full schema coverage, the description covers purpose, exclusion and the notable non-returned fields — enough to call it correctly. It stops short of addressing reversibility/cleanup or the idempotent retry path in prose, though both are partly covered elsewhere.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by telling the agent which supplied fields are persisted-but-not-echoed versus returned, which affects how it should report results back to the user. It adds nothing about businessId, legalEntity or requestId retry semantics, but those are already well documented in the schema.

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 ('add a new customer to a business') plus a concrete use case (a client about to be invoiced). It also distinguishes itself from the sibling update_customer with 'Not for changing an existing customer', so an agent can route correctly 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?

Gives an explicit trigger ('when someone asks to add a new customer'), a motivating example, and an explicit exclusion ('Not for changing an existing customer') that clearly points at update_customer among the siblings. Both the when and the when-not are stated.

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

find_customerFind a customer by nameA

Read-onlyIdempotent

Inspect

Use this when someone names a customer to update and you need that customer's id. Returns up to five customers whose name contains every word searched, each with its id, business and last edit time; never their contact details, tax id or address. Not for listing every customer.

Name	Required	Description	Default
`search`	Yes	The customer's name as the user gave it, or part of it. Every word must appear in the stored name, in any order, ignoring case and accents.
`businessId`	No	Only customers of this business; every business of the account when absent

Output Schema

Name	Required	Description
`count`	Yes
`customers`	Yes	The customers whose name matches, with the ids the other tools take. Contact details, dates of birth, notes and clinical records are never returned.
`tooManyMatches`	Yes	More than 5 customers match: none are returned; ask the user for more of the name

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered; the description then adds genuinely new behavior: a hard result cap of five, the word-containment matching rule, the exact fields returned, and an explicit privacy boundary (no contact details, tax id or address). That disclosure of what is deliberately withheld is exactly the kind of context annotations cannot carry.

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?

Two sentences, front-loaded with the trigger condition, then the return contract and the exclusion. There is no filler and every clause carries information the agent needs.

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?

With an output schema present, the description need not enumerate return fields, yet it still summarizes them and states the cap and the privacy exclusions. Combined with full schema coverage and rich annotations, nothing needed to invoke this correctly is missing.

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 coverage is 100% and the search parameter already documents the word-containment, order-insensitive, accent-insensitive matching, so the description's phrase "contains every word searched" largely restates the schema. It adds the five-result cap, which is a result behavior rather than parameter meaning, so the 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?

The description opens with a specific verb and resource ("find a customer... you need that customer's id") and immediately bounds the scope ("Not for listing every customer"), which separates it from list-style siblings and from update_customer. An agent can tell what this returns without opening the schema.

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?

It gives an explicit trigger condition ("when someone names a customer to update and you need that customer's id") and an explicit exclusion ("Not for listing every customer"). The only gap is that no sibling is named as the alternative for the listing case, so the agent must infer it from the tool list.

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

get_businessGet business detailsA

Read-onlyIdempotent

Inspect

Use this when someone asks about one business's invoicing setup, such as its currency, country, language or timezone. Returns the business's name, currency, country code, language and timezone, or not-found. Not for revenue or unpaid invoices.

Name	Required	Description	Default
`businessId`	Yes	Business id: 24 lowercase hexadecimal characters

Output Schema

Name	Required	Description
`status`	Yes
`business`	Yes	Null when not found. Contact, legal-entity, address, banking and integration fields are omitted.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare the safe read profile (readOnly, idempotent, non-destructive), so the lower bar applies; the description still adds the 'or not-found' outcome, which the annotations do not convey. It does not mention auth or rate-limit behavior, so it stops short of 5.

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?

Two tight sentences: the usage condition and return fields come first, and the exclusion is appended as a short guardrail. No filler or restated name/title.

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?

For a single-parameter read tool with annotations covering the safety profile and an output schema present, nothing needed to invoke it correctly is missing. Field enumeration is mildly redundant with the output schema but reinforces the invocation trigger.

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?

One parameter with 100% schema description coverage, including the 24-hex-char pattern, so the schema carries the full semantics. The description adds no extra meaning about businessId, which is the expected baseline when coverage is high.

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 ('one business's invoicing setup') and enumerates the fields involved (currency, country, language, timezone), which cleanly separates it from the revenue/receivables siblings. The explicit 'Not for revenue or unpaid invoices' sharpens the boundary further.

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?

Gives an explicit trigger ('when someone asks about one business's invoicing setup') and names the exclusions, implicitly routing the agent to get_revenue_summary and get_receivables_summary instead. Both when-to-use and when-not-to-use are present.

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

get_quote_pipeline_summarySummarize quotes and acceptanceA

Read-onlyIdempotent

Inspect

Use this when someone asks how many quotes or estimates they sent, what they were worth, or how many were accepted or rejected. Returns quote count, total value, counts by status and an acceptance rate; defaults to the last 90 days, at most 366, skipping drafts and counting at most 500 quotes. Not for a single quote.

Name	Required	Description
`endDate`	No	Last UTC day to include, YYYY-MM-DD, at most 366 days after startDate; defaults to today
`startDate`	No	First UTC day to include, YYYY-MM-DD; defaults to 89 days before endDate (a 90-day window)
`businessId`	Yes	Business id: 24 lowercase hexadecimal characters

Output Schema

Name	Required	Description
`range`	Yes
`currency`	Yes	ISO 4217 alpha-3 business currency, or null when unset
`quoteCount`	Yes
`quotedAmount`	Yes
`statusBreakdown`	Yes	Non-draft quotes issued in the range, per status, with count and amount. Quote and customer identifiers, contacts, tax ids, addresses, notes, line descriptions and free text are never returned.
`amountMissingCount`	Yes
`acceptanceRatePercent`	Yes	Approved quotes as a percentage of approved plus rejected; null when the count is a lower bound or none was decided
`quoteCountIsLowerBound`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already establish the safe-read profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds genuinely useful behavior beyond that: the 90-day default window, the 366-day cap, draft-skipping, and a 500-quote counting limit.

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?

Two sentences, front-loaded with the usage trigger followed by the returned fields and constraints. No filler or repetition; every clause carries information an agent needs.

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 an output schema present, the description needn't enumerate return values, and the annotations cover safety semantics. It supplies default window, caps, and draft exclusion, leaving only minor gaps such as permissions or rejection-handling nuances.

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 all three parameters (businessId, startDate, endDate) are already documented in the schema, including the date defaults and window cap. The description largely restates these; the extra 500-quote cap applies to results rather than a parameter, so the baseline 3 is appropriate.

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 (summarize) and resource (quotes/estimates), plus the exact outputs: quote count, total value, counts by status, and acceptance rate. This clearly distinguishes it from sibling tools like get_receivables_summary and get_revenue_summary, which cover different domains.

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?

Opens with a concrete user-intent trigger ("when someone asks how many quotes or estimates they sent, what they were worth, or how many were accepted or rejected") and adds an exclusion ("Not for a single quote"). It does not name a specific alternative tool for single-quote retrieval, but no such sibling exists in the list.

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

get_receivables_summaryCheck unpaid and overdue invoicesA

Read-onlyIdempotent

Inspect

Use this when someone asks how much customers owe, what is unpaid or overdue, or how old unpaid invoices are. Returns open invoice count and amount, the invoices marked overdue, and age buckets by days past due, from the newest 500 invoices; partially paid ones are counted but left out of amounts. Not for chasing or charging a customer.

Name	Required	Description	Default
`businessId`	Yes	Business id: 24 lowercase hexadecimal characters

Output Schema

Name	Required	Description
`aging`	Yes	Fully owed open invoices by days past their due date (issue date when none) as of asOfDate. Invoice and customer identifiers, exact dates, contacts, tax ids, addresses, notes, line text, bank or card data, processor data and payment actions are never returned.
`asOfDate`	Yes	UTC calendar date in YYYY-MM-DD format
`currency`	Yes	ISO 4217 alpha-3 business currency, or null when unset
`overdueAmount`	Yes
`openInvoiceCount`	Yes
`outstandingAmount`	Yes
`amountMissingCount`	Yes
`sourceInvoiceCount`	Yes
`overdueInvoiceCount`	Yes	Fully owed invoices whose status is OVERDUE; a PENDING invoice past its due date is counted only in aging
`sourceInvoiceCountIsLowerBound`	Yes
`partiallyPaidCountExcludedFromAmount`	Yes	Open partially paid invoices left out of every amount because their remaining balance is not stored

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the 500-newest-invoice cap and the quirk that partially paid invoices are counted but excluded from amounts. It doesn't mention auth or rate limits, but those are not implied by the annotations either.

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?

Three sentences, all load-bearing: usage trigger, return shape with caveats, and exclusion. The most decision-relevant information (what it's for) is front-loaded.

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?

Annotations cover the safety profile, an output schema exists so return structure need not be re-explained, and the description still supplies the non-obvious limits (500-invoice scope, partial-payment handling) and boundary against adjacent tools. Nothing an agent needs to call this correctly is missing.

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?

Only one parameter (businessId) and schema description coverage is 100%, with the schema documenting the 24-hex-character pattern. The description adds no additional meaning about the parameter, so the 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 resource (receivables) with concrete outcomes: open invoice count/amount, overdue invoices, and age buckets by days past due. An agent can distinguish this from get_revenue_summary or get_quote_pipeline_summary 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?

Gives explicit triggering conditions ('when someone asks how much customers owe, what is unpaid or overdue') and an explicit exclusion ('Not for chasing or charging a customer'). Both the when and the when-not are stated.

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

get_revenue_summarySummarize invoiced and paid amountsA

Read-onlyIdempotent

Inspect

Use this when someone asks how much they invoiced or were paid in a period, like last month. Returns invoice and payment counts and totals in the business currency, invoices by status and a collection rate; defaults to the last 90 days, at most 366, skipping drafts and counting at most 500 documents. Not for a single invoice or customer.

Name	Required	Description
`endDate`	No	Last UTC day to include, YYYY-MM-DD, at most 366 days after startDate; defaults to today
`startDate`	No	First UTC day to include, YYYY-MM-DD; defaults to 89 days before endDate (a 90-day window)
`businessId`	Yes	Business id: 24 lowercase hexadecimal characters

Output Schema

Name	Required	Description
`range`	Yes
`currency`	Yes	ISO 4217 alpha-3 business currency, or null when unset
`invoiceCount`	Yes
`paymentCount`	Yes
`invoicedAmount`	Yes
`collectedAmount`	Yes	Sum of the payments recorded in the range, whatever their status; not proof of bank settlement
`collectionRatePercent`	Yes	collectedAmount as a percentage of invoicedAmount; null when a total is incomplete or nothing was invoiced
`invoiceStatusBreakdown`	Yes	Non-draft invoices issued in the range, per status, with count and amount. Aggregates only: invoice, payment, customer, line-item, processor, card, bank, note and identifier data are never returned.
`invoiceCountIsLowerBound`	Yes
`paymentCountIsLowerBound`	Yes
`invoiceAmountMissingCount`	Yes
`paymentAmountMissingCount`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real behavioral context beyond them: a default 90-day window, a hard 366-day ceiling, that drafts are skipped, and that at most 500 documents are counted. These are exactly the silent constraints that would otherwise cause a wrong call.

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?

Two sentences, front-loaded with the trigger phrase and followed by the return payload and the scoping limit. No filler, and the exclusion is placed last as a natural boundary.

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?

With an output schema present, return-value detail is optional, yet the description briefly signals the shape (counts, totals, status breakdown, collection rate). Combined with the default window, caps, draft exclusion, and scope boundary, an agent has everything needed to call it correctly.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3 and the schema already documents businessId, startDate, and endDate formats and defaults. The description nonetheless reinforces the window semantics (default 90 days, cap 366) and adds a non-parameter constraint (500-document counting cap), slightly exceeding the baseline.

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 ('how much they invoiced or were paid in a period') and enumerates the returned artifacts: invoice and payment counts and totals in business currency, invoices by status, and a collection rate. The closing exclusion ('Not for a single invoice or customer') further sharpens its scope against narrower siblings.

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?

Gives an explicit trigger ('Use this when someone asks how much they invoiced or were paid in a period, like last month') and an explicit when-not ('Not for a single invoice or customer'). It stops short of naming which sibling to use instead for per-customer or receivables questions, so routing between get_receivables_summary and this tool is left to inference.

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

get_subscriptionCheck InvoiceVista plan and limitsA

Read-onlyIdempotent

Inspect

Use this when someone asks which InvoiceVista plan a business is on, or how many customers, invoices or users it allows. Returns the active or past-due plan's name, status, billing frequency and limits, or the Free plan's defaults when there is none. Not for customer invoices or payments.

Name	Required	Description	Default
`businessId`	Yes	Business id: 24 lowercase hexadecimal characters

Output Schema

Name	Required	Description
`status`	Yes
`subscription`	Yes	Plan entitlements; limits are caps, not usage. Payment-processor identifiers and credentials are never returned.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds real behavioral context beyond that: it returns the active OR past-due plan, and falls back to Free plan defaults when no plan exists — a non-obvious edge case an agent would otherwise have to discover at runtime.

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?

Two sentences with zero filler: usage trigger first, return contract and boundary second. Every clause earns its place, and nothing is buried.

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?

An output schema exists, so return-shape detail is already structured; the description still summarizes the useful cases (active, past-due, no-plan fallback). With a single well-documented parameter and full annotation coverage, nothing needed to call this correctly is missing.

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?

Only one parameter, and schema coverage is 100% — the schema documents businessId including its 24-hex-character pattern. The description adds nothing about the parameter, so the baseline 3 applies when structured data does all the work.

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+resource (retrieve the InvoiceVista subscription plan for a business) and enumerates exactly what it yields: plan name, status, billing frequency and limits. The closing sentence distinguishes it from sibling reporting tools by ruling out customer invoices and payments.

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?

Opens with an explicit trigger ('Use this when someone asks which plan a business is on, or how many customers, invoices or users it allows') and adds an explicit exclusion ('Not for customer invoices or payments'). Both when-to-use and when-not-to-use are present, so no inference is required.

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

list_businessesList your businessesA

Read-onlyIdempotent

Inspect

Use this when someone asks which businesses they invoice from in InvoiceVista, or a business's id is needed. Returns each business's id, name, currency, country, language and timezone, 25 per page by default (no addresses or bank details). Not for listing customers.

Name	Required	Description	Default
`limit`	No	Businesses per page, from 1 to 100; defaults to 25
`cursor`	No	The nextCursor of the previous page of this listing; absent for the first page

Output Schema

Name	Required	Description
`items`	Yes	Businesses in the signed-in organization. Addresses, contact details, payment settings and secrets are omitted.
`hasMore`	Yes
`nextCursor`	No	Cursor for the next page; absent on the last page

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely useful context beyond that: the default page size, what is deliberately omitted (addresses, bank details), and the field set returned. It stops short of explaining pagination via cursor, but that is largely in the schema.

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?

Three tight sentences, front-loaded with the trigger condition, then the payload shape, then the exclusion. No filler or redundancy.

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?

Complete for a two-parameter, zero-required listing tool. An output schema exists, yet the description helpfully summarizes the returned fields and pagination default, and the omission of addresses/bank details preempts wrong expectations.

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 limit and cursor are fully documented in the schema, which sets the baseline at 3. The description's mention of '25 per page by default' corroborates the limit parameter but adds no cursor semantics beyond the schema.

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 businesses) plus the exact fields returned (id, name, currency, country, language, timezone) and the page size. It explicitly distinguishes itself from the sibling case by noting 'Not for listing customers'.

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?

Gives concrete triggering conditions ('when someone asks which businesses they invoice from, or a business's id is needed') and an explicit exclusion ('Not for listing customers'). An agent can route to or away from this tool without inspecting siblings.

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

list_inventory_itemsCheck stockA

Read-onlyIdempotent

Inspect

Use this when someone asks how much of a material, product or supply a business has left in stock, or what is running low. Returns up to 100 stock items with unit, quantity, minimum and a low-stock flag. Not for the prices a business charges.

Name	Required	Description
`limit`	No	Maximum number of items (default 50, maximum 100).
`search`	No	Only items whose name contains these words.
`businessId`	No	Business id: 24 lowercase hexadecimal characters; may be absent when the account has one business.
`lowStockOnly`	No	Only items at or below their minimum quantity.

Output Schema

Name	Required	Description
`count`	Yes
`items`	Yes
`hasMore`	Yes
`businessId`	Yes

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the 100-item result cap and notes it surfaces a low-stock flag, but the output schema already defines returned fields, so the incremental behavioral disclosure is modest.

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?

Three short sentences: trigger first, then what is returned, then the exclusion. No filler and the most decision-relevant information is front-loaded.

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 rich annotations, full schema coverage and an output schema, the description only needs to establish purpose and scope, which it does. The one gap is that it does not point at the mutation sibling (set_inventory_quantity) or explain pagination beyond the 100-item ceiling, which is minor given the structured fields.

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 all four parameters (limit, search, businessId, lowStockOnly) are documented there, including the default of 50 and the 100 maximum. The description adds no parameter-level meaning beyond restating the 100-item return cap, 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?

The description states a concrete verb and resource ('how much of a material, product or supply a business has left in stock') and describes the returned fields (unit, quantity, minimum, low-stock flag). The closing exclusion ('Not for the prices a business charges') separates it from pricing-oriented siblings such as list_products.

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?

It gives an explicit triggering situation ('when someone asks how much ... is left in stock, or what is running low') and one clear out-of-scope case (prices). It does not name the natural counterpart set_inventory_quantity or list_products as alternatives, so the when-not guidance is incomplete rather than exhaustive.

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

list_productsList products and pricesA

Read-onlyIdempotent

Inspect

Use this when someone asks what products or services a business sells or what it charges for them. Returns each catalog item's name, price and stored tax value, most recently edited first, 25 per page by default. Not for what a customer was invoiced.

Name	Required	Description
`limit`	No	Products per page, from 1 to 100; defaults to 25
`cursor`	No	The nextCursor of the previous page of this listing; absent for the first page
`businessId`	Yes	Business id: 24 lowercase hexadecimal characters

Output Schema

Name	Required	Description
`items`	Yes	Catalog items, most recently edited first. price is in the business currency; tax is the product's stored tax value, null when unset. Record identifiers, line-item text and customer data are excluded.
`hasMore`	Yes
`nextCursor`	No	Cursor for the next page; absent on the last page

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds genuinely new behavior: result ordering (most recently edited first) and default page size (25 per page), which the agent cannot infer from the annotations.

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?

Three sentences, no filler: the trigger comes first, then return/ordering/pagination facts, then the exclusion. Every sentence earns its place.

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 an output schema present, the description need not enumerate return values, and it still adds ordering and paging context. Cursor mechanics are left to the schema, which documents them fully, so the definition is essentially complete for this read-only listing tool.

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 every parameter already carries format and range documentation; the description only restates limit's default of 25. Baseline 3 is appropriate when the schema does the parameter work.

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 catalog products/services with prices) and explicitly scopes what it is not (what a customer was invoiced), which cleanly separates it from the invoice/receivables-oriented siblings.

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?

Opens with an explicit trigger condition ('when someone asks what products or services a business sells or what it charges') and adds a negative boundary ('Not for what a customer was invoiced'), so the agent knows both when and when not to reach for it.

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

open_invoicevistaInvoiceVista Invoice MakerA

Read-onlyIdempotent

Inspect

Use this when someone wants to open InvoiceVista and browse their businesses, billing overview, revenue, receivables and quote pipeline in an interactive sidebar. Returns up to 100 businesses to start from (no customer or individual financial records). Not for creating invoices or recording payments.

Name	Required	Description	Default
No parameters

Output Schema

Name	Required	Description
`items`	Yes
`truncated`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds useful scope context: the interactive sidebar nature, the 100-business cap, and the explicit exclusion of customer or individual financial records, which tells the agent what this tool will not surface. Minor gap: no mention of how the interactive session terminates or refreshes, but that is marginal. No contradiction with annotations.

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?

Two sentences, front-loaded with the primary trigger ('when someone wants to open InvoiceVista'), followed by scope and exclusions. Every phrase earns its place; no filler or repetition of annotation data.

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?

Given an output schema exists, the description rightly avoids explaining return values and instead focuses on trigger, scope cap, and exclusions. Combined with annotations that cover safety and idempotency, an agent has everything needed to call this correctly.

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

Parameters4/5

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

Zero parameters, so schema coverage is effectively complete and there is nothing to document. The baseline for 0 params is 4, and the description appropriately does not invent or confuse any parameter semantics.

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+resource ('open InvoiceVista') and enumerates exactly what surfaces appear (businesses, billing overview, revenue, receivables, quote pipeline). It also distinguishes from siblings by clarifying it returns up to 100 businesses rather than the focused summaries that get_receivables_summary or get_quote_pipeline_summary provide.

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?

Explicitly states when to use it ('when someone wants to open InvoiceVista and browse') and when not to ('Not for creating invoices or recording payments'). This gives a clear routing decision against the sibling read-only summary tools.

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

set_inventory_quantityUpdate a stock quantityA

DestructiveIdempotent

Inspect

Use this when someone asks to correct or update how much of an item a business has in stock, such as after a count or a delivery. Returns the item with its previous and new quantity; the number given replaces the stored one. Not for adding a new stock item.

Name	Required	Description
`quantity`	Yes	The quantity now in stock, in the item unit. It replaces the stored quantity rather than adding to it.
`inventoryItemId`	Yes	Stock item id: 24 lowercase hexadecimal characters.
`expectedLastEditTime`	Yes	The item's lastEditTime as last read; an item changed since then is refused.

Output Schema

Name	Required	Description
`item`	Yes
`status`	Yes
`previousQuantity`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare idempotentHint=true, destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds return contents (previous and new quantity) and that the value replaces rather than adds, but it omits the optimistic-concurrency refusal and the destructive nature of overwriting a prior count, both of which live only in the schema.

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 short sentences with zero filler, front-loaded with the usage trigger before the behavioral detail. Tight and readable, though the return-value sentence could be trimmed since an output schema exists.

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?

Complete for a three-parameter mutation: purpose, exclusion, replace semantics and return shape are all stated, and an output schema covers return values. A note about the concurrency check failing or about permission requirements would close the remaining gap for a destructive write.

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 all three parameters, including the expectedLastEditTime guard and id format, are documented in the schema. The description reinforces replace-not-add semantics for quantity but adds nothing beyond the schema text, making the baseline 3 appropriate.

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 ('correct or update how much of an item a business has in stock') plus the triggering situations (after a count or a delivery). It also explicitly excludes the adjacent create operation, so an agent can separate it from list_inventory_items and from item creation.

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?

Gives clear when-to-use context ('when someone asks to correct or update... after a count or a delivery') and a when-not condition ('Not for adding a new stock item'). It does not name a concrete alternative tool, since the create counterpart is not in the sibling list, but the exclusion still routes the agent away from a wrong write.

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

show_business_overviewShow business overviewA

Read-onlyIdempotent

Inspect

Use this when someone wants a quick overview or dashboard of one business in InvoiceVista. Returns an overview card with the business details, counts of customers, invoices, payments and quotes with status mixes (each capped at 100), and up to 12 catalog products (no customer or invoice details). Not for revenue over a period.

Name	Required	Description	Default
`businessId`	Yes	Business id: 24 lowercase hexadecimal characters

Output Schema

Name	Required	Description
`business`	Yes	Null when not found. Individual customer or financial records, identifiers, numbers, exact dates or amounts, contacts, tax ids, addresses, notes, line descriptions, PCI or bank data, processor data, credentials and payment actions are never returned.
`products`	Yes
`quoteCount`	Yes
`invoiceCount`	Yes
`paymentCount`	Yes
`productCount`	Yes
`customerCount`	Yes
`quoteStatusBreakdown`	Yes
`invoiceStatusBreakdown`	Yes
`quoteCountIsLowerBound`	Yes
`invoiceCountIsLowerBound`	Yes
`paymentCountIsLowerBound`	Yes
`productCountIsLowerBound`	Yes
`customerCountIsLowerBound`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuine behavioral detail beyond them: per-status counts are capped at 100 and only up to 12 catalog products are returned, and it explicitly excludes customer/invoice details.

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 that front-load the use case and then the payload shape; every clause carries information. 'quick overview or dashboard' is mildly redundant but overall there is little waste.

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?

For a single-parameter read tool with full annotations and an output schema, nothing needed to invoke it correctly is missing. The description goes beyond the minimum by describing caps, product limits, and excluded data.

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 businessId parameter is fully documented (24 lowercase hex chars), so the schema does the work. The description adds no syntax or format detail for the parameter, which is the expected baseline when the schema is complete.

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 (shows a business overview card) and enumerates the exact payload: business details, counts of customers/invoices/payments/quotes with status mixes, and up to 12 catalog products. It also carves itself away from a sibling with 'Not for revenue over a period', so an agent can distinguish it from get_revenue_summary without opening schemas.

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?

Gives a clear use condition ('when someone wants a quick overview or dashboard of one business') and an explicit exclusion ('Not for revenue over a period'). It stops short of naming the alternative sibling tool by name, leaving the agent to infer get_revenue_summary from the sibling list.

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

update_customerUpdate a customer's detailsA

DestructiveIdempotent

Inspect

Use this when someone asks to change a customer's name, email, phone, tax id, address or language. Returns the customer's id, name, business and which fields changed; contact details, tax ids and addresses are never returned. Not for adding a new customer.

Name	Required	Description
`name`	No	New full or company name.
`email`	No	New email address for their invoices.
`phone`	No	New mobile number, with the country code when known.
`taxId`	No	New tax or VAT number.
`address`	No	Billing address lines to change. Lines left out keep their stored value.
`language`	No	New language for their invoices and messages, as a code such as en or it.
`customerId`	Yes	Customer id: 24 lowercase hexadecimal characters.
`legalEntity`	No	What kind of customer this is.
`expectedLastEditTime`	Yes	The customer's lastEditTime as last read; a customer changed since then is refused.

Output Schema

Name	Required	Description
`status`	Yes
`customer`	Yes
`changedFields`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare destructive, idempotent, non-read-only behavior, so the description need not repeat those. It adds meaningful context beyond the annotations by disclosing that contact details, tax ids and addresses are never returned and by summarizing which fields are returned after an update.

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?

Two sentences with no wasted wording, and the usage trigger is front-loaded before the exclusion and return details.

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?

Given rich annotations, an output schema and full schema descriptions, the description covers the remaining gaps: when to use it, what it is not for, and the sensitive return-field policy. Nothing material for correct invocation is missing.

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%, including the optimistic concurrency guard on expectedLastEditTime and the address merge behavior, so the schema already carries parameter meaning. The description only lists updatable fields and adds no syntax or format details beyond what the schema provides.

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?

The description names a specific verb and resource ('change a customer's name, email, phone, tax id, address or language') and explicitly excludes adding a new customer. An agent can distinguish this from create_customer 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 Guidelines4/5

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

It gives a clear when-to-use trigger and a when-not exclusion ('Not for adding a new customer'). It does not name the sibling alternative explicitly, but the exclusion routes the agent away from the wrong tool.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesNov 6, 2026
- Addedcreate_customer
- Addedfind_customer
- Addedlist_inventory_items
- Addedset_inventory_quantity
- Addedupdate_customer
2 tool updatesOct 3, 2026
- Changedget_quote_pipeline_summary3 fields changed
  - removedInput schema / properties / endDate / $ref
```
Removed value: -"#/properties/startDate"
```
  - addedInput schema / properties / endDate / pattern
```
Added value: +"^\\d{4}-\\d{2}-\\d{2}$"
```
  - addedInput schema / properties / endDate / type
```
Added value: +"string"
```
- Changedget_revenue_summary3 fields changed
  - removedInput schema / properties / endDate / $ref
```
Removed value: -"#/properties/startDate"
```
  - addedInput schema / properties / endDate / pattern
```
Added value: +"^\\d{4}-\\d{2}-\\d{2}$"
```
  - addedInput schema / properties / endDate / type
```
Added value: +"string"
```
1 tool updateOct 2, 2026
- Addedopen_invoicevista

1 tool updateOct 1, 2026

Changedget_subscription1 field changed

changedOutput schema / properties / subscription / anyOf

Previous value: -[
-  {
-    "additionalProperties": false,
-    "properties": {
-      "billingFrequency": {
-        "anyOf": [
-          {
-            "enum": [
-              "MONTHLY",
-              "YEARLY"
-            ],
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ]
-      },
-      "maxNumberOfCustomers": {
-        "type": [
-          "number",
-          "null"
-        ]
-      },
-      "maxNumberOfInvoices": {
-        "type": [
-          "number",
-          "null"
-        ]
-      },
-      "maxNumberOfReminders": {
-        "type": [
-          "number",
-          "null"
-        ]
-      },
-      "maxNumberOfUsers": {
-        "type": [
-          "number",
-          "null"
-        ]
-      },
-      "productName": {
-        "anyOf": [
-          {
-            "maxLength": 200,
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ]
-      },
-      "status": {
-        "anyOf": [
-          {
-            "enum": [
-              "ACTIVE",
-              "PAST_DUE",
-              "CANCELED"
-            ],
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ]
-      }
-    },
-    "required": [
-      "status",
-      "productName",
-      "billingFrequency",
-      "maxNumberOfCustomers",
-      "maxNumberOfInvoices",
-      "maxNumberOfReminders",
-      "maxNumberOfUsers"
-    ],
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "billingFrequency": {
+        "anyOf": [
+          {
+            "enum": [
+              "MONTHLY",
+              "YEARLY"
+            ],
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "maxNumberOfCustomers": {
+        "type": [
+          "number",
+          "null"
+        ]
+      },
+      "maxNumberOfInvoices": {
+        "type": [
+          "number",
+          "null"
+        ]
+      },
+      "maxNumberOfUsers": {
+        "type": [
+          "number",
+          "null"
+        ]
+      },
+      "productName": {
+        "anyOf": [
+          {
+            "maxLength": 200,
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "status": {
+        "anyOf": [
+          {
+            "enum": [
+              "ACTIVE",
+              "PAST_DUE",
+              "CANCELED"
+            ],
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      }
+    },
+    "required": [
+      "status",
+      "productName",
+      "billingFrequency",
+      "maxNumberOfCustomers",
+      "maxNumberOfInvoices",
+      "maxNumberOfUsers"
+    ],
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

8 tool updatesSep 30, 2026

Changedget_business2 fields changed

changedInput schema / properties / businessId / description

Previous value: -"24-character lowercase hexadecimal business id"New value: +"Business id: 24 lowercase hexadecimal characters"

addedOutput schema / properties / business / description

Added value: +"Null when not found. Contact, legal-entity, address, banking and integration fields are omitted."

Changedget_quote_pipeline_summary5 fields changed

changedInput schema / properties / businessId / description

Previous value: -"Tenant-owned InvoiceVista business id"New value: +"Business id: 24 lowercase hexadecimal characters"

changedInput schema / properties / endDate / description

Previous value: -"Last UTC day to include; defaults to today"New value: +"Last UTC day to include, YYYY-MM-DD, at most 366 days after startDate; defaults to today"

changedInput schema / properties / startDate / description

Previous value: -"First UTC day to include; defaults to 89 days before endDate"New value: +"First UTC day to include, YYYY-MM-DD; defaults to 89 days before endDate (a 90-day window)"

addedOutput schema / properties / acceptanceRatePercent / description

Added value: +"Approved quotes as a percentage of approved plus rejected; null when the count is a lower bound or none was decided"

addedOutput schema / properties / statusBreakdown / description

Added value: +"Non-draft quotes issued in the range, per status, with count and amount. Quote and customer identifiers, contacts, tax ids, addresses, notes, line descriptions and free text are never returned."

Changedget_receivables_summary4 fields changed

changedInput schema / properties / businessId / description

Previous value: -"Tenant-owned InvoiceVista business id"New value: +"Business id: 24 lowercase hexadecimal characters"

addedOutput schema / properties / aging / description

Added value: +"Fully owed open invoices by days past their due date (issue date when none) as of asOfDate. Invoice and customer identifiers, exact dates, contacts, tax ids, addresses, notes, line text, bank or card data, processor data and payment actions are never returned."

addedOutput schema / properties / overdueInvoiceCount / description

Added value: +"Fully owed invoices whose status is OVERDUE; a PENDING invoice past its due date is counted only in aging"

addedOutput schema / properties / partiallyPaidCountExcludedFromAmount / description

Added value: +"Open partially paid invoices left out of every amount because their remaining balance is not stored"

Changedget_revenue_summary6 fields changed

changedInput schema / properties / businessId / description

Previous value: -"Tenant-owned InvoiceVista business id"New value: +"Business id: 24 lowercase hexadecimal characters"

changedInput schema / properties / endDate / description

Previous value: -"Last UTC day to include; defaults to today"New value: +"Last UTC day to include, YYYY-MM-DD, at most 366 days after startDate; defaults to today"

changedInput schema / properties / startDate / description

Previous value: -"First UTC day to include; defaults to 89 days before endDate"New value: +"First UTC day to include, YYYY-MM-DD; defaults to 89 days before endDate (a 90-day window)"

addedOutput schema / properties / collectedAmount / description

Added value: +"Sum of the payments recorded in the range, whatever their status; not proof of bank settlement"

addedOutput schema / properties / collectionRatePercent / description

Added value: +"collectedAmount as a percentage of invoicedAmount; null when a total is incomplete or nothing was invoiced"

addedOutput schema / properties / invoiceStatusBreakdown / description

Added value: +"Non-draft invoices issued in the range, per status, with count and amount. Aggregates only: invoice, payment, customer, line-item, processor, card, bank, note and identifier data are never returned."

Changedget_subscription2 fields changed

changedInput schema / properties / businessId / description

Previous value: -"24-character lowercase hexadecimal business id"New value: +"Business id: 24 lowercase hexadecimal characters"

addedOutput schema / properties / subscription / description

Added value: +"Plan entitlements; limits are caps, not usage. Payment-processor identifiers and credentials are never returned."

Changedlist_businesses4 fields changed

changedInput schema / properties / cursor / description

Previous value: -"Opaque cursor from a previous page"New value: +"The nextCursor of the previous page of this listing; absent for the first page"

addedInput schema / properties / limit / description

Added value: +"Businesses per page, from 1 to 100; defaults to 25"

addedOutput schema / properties / items / description

Added value: +"Businesses in the signed-in organization. Addresses, contact details, payment settings and secrets are omitted."

addedOutput schema / properties / nextCursor / description

Added value: +"Cursor for the next page; absent on the last page"

Changedlist_products5 fields changed

changedInput schema / properties / businessId / description

Previous value: -"Tenant-owned InvoiceVista business id"New value: +"Business id: 24 lowercase hexadecimal characters"

changedInput schema / properties / cursor / description

Previous value: -"Opaque cursor from a previous page"New value: +"The nextCursor of the previous page of this listing; absent for the first page"

addedInput schema / properties / limit / description

Added value: +"Products per page, from 1 to 100; defaults to 25"

addedOutput schema / properties / items / description

Added value: +"Catalog items, most recently edited first. price is in the business currency; tax is the product's stored tax value, null when unset. Record identifiers, line-item text and customer data are excluded."

addedOutput schema / properties / nextCursor / description

Added value: +"Cursor for the next page; absent on the last page"

Changedshow_business_overview2 fields changed

changedInput schema / properties / businessId / description

Previous value: -"Tenant-owned InvoiceVista business id"New value: +"Business id: 24 lowercase hexadecimal characters"

addedOutput schema / properties / business / description

Added value: +"Null when not found. Individual customer or financial records, identifiers, numbers, exact dates or amounts, contacts, tax ids, addresses, notes, line descriptions, PCI or bank data, processor data, credentials and payment actions are never returned."

8 tool updatesSep 25, 2026
- First observedget_business
- First observedget_quote_pipeline_summary
- First observedget_receivables_summary
- First observedget_revenue_summary
- First observedget_subscription
- First observedlist_businesses
- First observedlist_products
- First observedshow_business_overview

Related MCP Connectors

Bookipi
io.github.Bookipi-Group
Invoices, payments, expenses, customers, deals, proposals, eSign and reports for small businesses.
Finance Payments & Billing CRM
1
https://mcp.bookipi.com/mcp
bookkeeping
io.helloledger
Bookkeeping for owner-operated businesses. Query transactions, invoices, and reports.
Finance Payments & Billing
1
https://mcp.helloledger.io/mcp
SuperBooksA
io.superbooks
Financial OS for small businesses: transactions, invoices, customers, time tracking and reports.
CRM ERP Systems Finance
21
https://app.superbooks.io/mcp
Setttle
ca.setttle
Read and update double-entry books: accounts, invoices, bills, bank activity and reports.
Finance ERP Systems
1
https://api.setttle.ca/mcp

Related MCP Servers

BizDesk MCP
CRM Finance
syedahmad0786
A
license
Not graded
quality
C
maintenance
Provides structured, read-mostly access to small-business back-office data including customers, invoices, and account notes, allowing Claude to query overdue invoices, revenue summaries, and more.
Updated 4 months ago (2026-07-17 03:11 UTC)
MIT
Frihet MCP Server
ERP Systems Finance App Automation
Frihet-io
A
license
B
quality
A
maintenance
AI-native business management — invoices, expenses, clients, products, quotes, and webhooks. 31 tools for Claude, Cursor, Windsurf, and Cline.
Updated 5 days ago (2026-11-02 01:54 UTC)
100
497 npm
13
MIT
wave-mcp-server
Finance Payments & Billing ERP Systems
yoyodyne7
A
license
A
quality
C
maintenance
Enables MCP clients to work with Wave invoicing for a single business, including looking up customers and invoices, creating customers and draft invoices, and approving, sending, or recording payments behind a preview-then-confirm step.
Updated 21 days ago (2026-10-16 13:11 UTC)
17
22 npm
MIT
mcp-quickbooks
Finance ERP Systems
pipeworx-io
A
license
Not graded
quality
C
maintenance
Query customers, invoices, and accounts via QuickBooks Online API.
Updated 9 days ago (2026-10-29 05:54 UTC)
224 npm
MIT

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?