Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Wave MCP Server list all unpaid invoices from last month"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A complete Model Context Protocol (MCP) server for Wave Accounting, providing comprehensive access to invoicing, customers, products, transactions, bills, estimates, taxes, and financial reporting.
List, get, create, update, delete invoices
Send invoices via email
Approve and mark invoices as sent
List and record invoice payments
List, get, create, update, delete customers
Search customers by name or email
List, get, create, update, archive products and services
Filter by sold/bought status
List, get, create, update chart of accounts
Filter by account type (ASSET, LIABILITY, EQUITY, INCOME, EXPENSE)
List, get, create, update transactions
Categorize transactions to accounts
List transaction attachments
List, get, create, update bills (accounts payable)
List and record bill payments
List, get, create, update, send estimates
Convert estimates to invoices
List, get, create sales taxes
List businesses
Get current or specific business details
Profit & Loss (Income Statement)
Balance Sheet
Aged Receivables (A/R Aging)
Tax Summary
Cashflow Statement
invoice-dashboard - Overview of invoices with status breakdown
invoice-detail - Detailed invoice view with payments and actions
invoice-builder - Create/edit invoices with line items
customer-detail - Customer profile with invoice history
customer-grid - Searchable customer grid
product-catalog - Product/service management
chart-of-accounts - Account tree view
transaction-feed - Real-time transaction stream
transaction-categorizer - Bulk transaction categorization
bill-manager - Track and pay bills
estimate-builder - Create and manage quotes
tax-overview - Tax configuration and summary
profit-loss - P&L report with visualization
balance-sheet - Balance sheet report
cashflow-chart - Cashflow waterfall chart
aging-report - Aged receivables report
business-overview - Business dashboard with quick actions
Related MCP server: waveapps-mcp
cd servers/wave
npm install
npm run buildWave Account: You need a Wave account at waveapps.com
API Access Token: Get an OAuth2 access token from Wave Developer Portal
# Required
WAVE_ACCESS_TOKEN=your_oauth2_access_token
# Optional - set a default business ID
WAVE_BUSINESS_ID=your_business_idRun the server:
WAVE_ACCESS_TOKEN=your_token npm run devAdd to your claude_desktop_config.json:
{
"mcpServers": {
"wave": {
"command": "node",
"args": ["/path/to/mcpengine-repo/servers/wave/build/main.js"],
"env": {
"WAVE_ACCESS_TOKEN": "your_access_token",
"WAVE_BUSINESS_ID": "optional_business_id"
}
}
}
}npx @mcpengine/wave-server// List all invoices
wave_list_invoices({ businessId: "business_123" })
// Filter by status
wave_list_invoices({
businessId: "business_123",
status: "OVERDUE"
})
// Filter by customer
wave_list_invoices({
businessId: "business_123",
customerId: "customer_456"
})wave_create_invoice({
businessId: "business_123",
customerId: "customer_456",
invoiceDate: "2025-01-15",
dueDate: "2025-02-15",
title: "January Services",
items: [
{
description: "Consulting Services",
quantity: 10,
unitPrice: "150.00",
taxIds: ["tax_789"]
},
{
productId: "product_101",
description: "Software License",
quantity: 1,
unitPrice: "500.00"
}
]
})wave_create_customer({
businessId: "business_123",
name: "Acme Corporation",
email: "billing@acme.com",
addressLine1: "123 Main Street",
city: "San Francisco",
provinceCode: "CA",
countryCode: "US",
postalCode: "94105"
})// Profit & Loss
wave_profit_and_loss({
businessId: "business_123",
startDate: "2025-01-01",
endDate: "2025-01-31"
})
// Balance Sheet
wave_balance_sheet({
businessId: "business_123",
asOfDate: "2025-01-31"
})
// Aged Receivables
wave_aged_receivables({
businessId: "business_123",
asOfDate: "2025-01-31"
})Wave uses a GraphQL API, not REST. The server handles:
Authentication: OAuth2 Bearer token
Error Handling: GraphQL error parsing and network error detection
Type Safety: Full TypeScript types for all Wave entities
Pagination: Automatic page handling for large result sets
// client.ts
import { GraphQLClient } from 'graphql-request';
const client = new GraphQLClient('https://gql.waveapps.com/graphql/public', {
headers: {
Authorization: `Bearer ${accessToken}`
}
});src/tools/
├── invoices-tools.ts # 10 tools for invoice management
├── customers-tools.ts # 6 tools for customer management
├── products-tools.ts # 5 tools for product/service catalog
├── accounts-tools.ts # 4 tools for chart of accounts
├── transactions-tools.ts # 6 tools for transaction management
├── bills-tools.ts # 7 tools for bills payable
├── estimates-tools.ts # 6 tools for estimates/quotes
├── taxes-tools.ts # 3 tools for sales tax management
├── businesses-tools.ts # 3 tools for business info
└── reporting-tools.ts # 5 tools for financial reportsComplete TypeScript types for all Wave entities:
// types/index.ts
export interface Invoice {
id: string;
invoiceNumber: string;
customer: Customer;
status: 'DRAFT' | 'SENT' | 'VIEWED' | 'PAID' | 'PARTIAL' | 'OVERDUE' | 'APPROVED';
items: InvoiceItem[];
total: Money;
amountDue: Money;
amountPaid: Money;
// ... full type definitions
}The server provides comprehensive error handling:
try {
const invoice = await wave_get_invoice({ invoiceId: "inv_123" });
} catch (error) {
// GraphQL errors
if (error.graphQLErrors) {
console.error('GraphQL errors:', error.graphQLErrors);
}
// Network errors
if (error.networkError) {
console.error('Network error:', error.networkError);
}
// HTTP status codes
if (error.statusCode) {
console.error('HTTP status:', error.statusCode);
}
}Apps are accessed via resources:
// List all apps
const apps = await readResource({ uri: "wave://apps" });
// Load specific app
const invoiceDashboard = await readResource({
uri: "wave://apps/invoice-dashboard"
});Each app includes:
Display name and description
Default tools to load
Layout configuration for UI rendering
Workflow steps (for process-driven apps)
npm run buildnpm run watchnpx tsc --noEmitMIT
Contributions welcome! Please see the main MCPEngine repository for guidelines.
For issues or questions:
Wave API issues: Wave Developer Support
MCP Server issues: GitHub Issues
Generate an Aged Receivables (A/R Aging) report
| Name | Required | Description | Default |
|---|---|---|---|
| asOfDate | No | Report as-of date (YYYY-MM-DD, defaults to today) | |
| businessId | No | Business ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It does not disclose whether the tool is read-only, whether it requires specific permissions, or what happens if data is missing. The minimal description fails to add transparency beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no extraneous words. While it could include more context, it is front-loaded and efficiently states the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should provide more context about what the report includes, how parameters affect output, or any limitations. It lacks sufficient detail for a complete understanding of tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters documented (asOfDate and businessId). The description adds no meaning beyond the schema's built-in descriptions. Since schema already does the work, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates an Aged Receivables (A/R Aging) report. The verb 'Generate' and specific resource 'A/R Aging report' make the purpose unambiguous and differentiate it from sibling report tools like wave_balance_sheet or wave_cashflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., other reports). The description lacks context about appropriate usage scenarios or any preconditions for generating the report.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Approve a draft invoice
| Name | Required | Description | Default |
|---|---|---|---|
| invoiceId | Yes | Invoice ID | |
| businessId | No | Business ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Approve a draft invoice' but does not describe side effects, state changes (e.g., invoice becomes approved), irreversibility, or required permissions. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at four words, with no wasted text. It is front-loaded and to the point. However, the brevity borders on under-specification, as it lacks important context about the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple action (approving a draft invoice) and minimal parameter count, the description is minimally adequate. However, it lacks information about return values, error conditions, or expected state changes. With no output schema, more context would be beneficial for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both parameters ('Invoice ID' and 'Business ID'). The description adds no additional meaning beyond what the schema already provides. Baseline score of 3 applies since schema descriptions are adequate but the tool description does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Approve') and a clear resource ('a draft invoice'), which clearly indicates the action and object. It distinguishes from siblings like wave_mark_invoice_sent by focusing on approval rather than marking as sent. However, it could be more explicit about what approving entails (e.g., finalizing, changing status) to avoid ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over alternatives such as wave_mark_invoice_sent or wave_update_invoice. There is no mention of prerequisites (e.g., invoice must be in draft state) or typical use cases. The agent must infer context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a Balance Sheet report
| Name | Required | Description | Default |
|---|---|---|---|
| asOfDate | Yes | Report as-of date (YYYY-MM-DD) | |
| businessId | No | Business ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits, but it only states 'Generate a Balance Sheet report'. It does not mention if the report is read-only, if it requires specific permissions, or any other behavioral aspects like pagination or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core purpose without any unnecessary words or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema and the description does not explain what the Balance Sheet report contains or how to interpret the results. Given the complexity of financial reports, this is insufficient for an agent to understand the tool's full capability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has clear descriptions for both parameters (asOfDate and businessId) with 100% coverage. The description adds no additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a Balance Sheet report, which is a specific and common financial statement. It distinguishes itself from sibling tools like wave_profit_and_loss and wave_tax_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other report tools, such as wave_profit_and_loss or wave_cashflow. No prerequisites or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a cashflow statement for a date range
| Name | Required | Description | Default |
|---|---|---|---|
| endDate | Yes | Report end date (YYYY-MM-DD) | |
| startDate | Yes | Report start date (YYYY-MM-DD) | |
| businessId | No | Business ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states 'generate', implying a read operation, but doesn't confirm side effects, permissions, or data impacts. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the key action. It is appropriately concise, though could benefit from more detail without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain what the generated cashflow statement includes or returns. It lacks this context. Also, no mention of required permissions or optional params like businessId. Incomplete for a report generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so the schema already describes the parameters. The description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Generate' and the resource 'cashflow statement', making the purpose specific. It distinguishes from sibling report tools like balance sheet or profit and loss, though it does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., when to choose cashflow over balance sheet). There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Categorize/recategorize a transaction to a different account
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | Yes | New account ID for categorization | |
| businessId | No | Business ID | |
| transactionId | Yes | Transaction ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only states the action but discloses no behavioral traits such as mutation, idempotency, prerequisites, or side effects. The agent has no insight into safety or implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is highly concise and front-loads the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no annotations, the description is too minimal. It lacks information about return values, error cases, prerequisites, or the effect of categorization, making it incomplete for a transaction-altering operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema's brief parameter descriptions. It does not clarify parameter constraints, sources, or formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Categorize/recategorize a transaction to a different account', which provides a specific verb and resource. However, it does not distinguish from the similar sibling tool 'wave_update_transaction' that might also allow changing the account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like wave_update_transaction. There are no explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert an approved estimate into an invoice
| Name | Required | Description | Default |
|---|---|---|---|
| dueDate | No | Invoice due date (YYYY-MM-DD) | |
| businessId | No | Business ID | |
| estimateId | Yes | Estimate ID | |
| invoiceDate | No | Invoice date (YYYY-MM-DD, defaults to today) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the core action but fails to disclose side effects (e.g., whether the estimate is marked as converted), permission requirements, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no extraneous words. While very concise, it sacrifices some detail that could be included without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is too minimal. It does not explain the return value, constraints (e.g., businessId requirement), or what happens to the original estimate, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents each parameter. The description adds no extra meaning beyond the schema, meeting the baseline but not exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('convert' + 'estimate into invoice') and includes the critical qualifier 'approved', clearly distinguishing it from sibling tools like wave_create_invoice (which creates from scratch) or wave_create_estimate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an approved estimate exists, but it lacks explicit guidance on when not to use it (e.g., if the estimate is not approved) and does not mention alternative tools or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new account in the chart of accounts
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Account name | |
| type | Yes | Account type: ASSET, LIABILITY, EQUITY, INCOME, EXPENSE | |
| subtype | No | Account subtype code | |
| currency | No | Currency code (e.g., USD) | |
| businessId | No | Business ID | |
| description | No | Account description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the action. No behavioral traits beyond creation are disclosed. For a write operation with no annotations, it should mention side effects, auth requirements, or constraints (e.g., uniqueness of account name).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is concise and front-loaded. Every word is necessary and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple creation tool with a comprehensive schema. However, the lack of output schema and annotations means the description could be more complete by explaining the return value or confirmation behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add any parameter-specific meaning beyond the schema. It does not explain the relationship between parameters or provide format hints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new account in the chart of accounts. It uses a specific verb ('Create') and resource ('account in the chart of accounts'), and is distinct from siblings like wave_list_accounts and wave_update_account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The verb 'Create' implies it is for new accounts, but prerequisites (e.g., need a business ID) or scenarios for updating vs. creating are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new bill
| Name | Required | Description | Default |
|---|---|---|---|
| memo | No | Internal memo | |
| items | Yes | Bill line items | |
| dueDate | No | Due date (YYYY-MM-DD) | |
| billDate | Yes | Bill date (YYYY-MM-DD) | |
| vendorId | Yes | Vendor ID | |
| billNumber | No | Bill number/reference | |
| businessId | No | Business ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral details (e.g., permissions needed, side effects, idempotency). This leaves the agent unsure about the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (three words), which is concise but fails to add value. It is not structured to aid agent understanding beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, 3 required, and no output schema, the description is insufficient. It should hint at behavior, return values, or when to use. Current description is too minimal for a complex creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no parameter meaning beyond what the schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new bill' is clear in stating the action and object, but it does not distinguish this tool from siblings like wave_create_invoice or wave_create_estimate. Without additional context, an agent might misselect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., wave_create_bill_payment, wave_create_transaction). The description lacks context about prerequisites or post-conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a payment made for a bill
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Payment date (YYYY-MM-DD) | |
| amount | Yes | Payment amount | |
| billId | Yes | Bill ID | |
| source | No | Payment source/method | |
| businessId | No | Business ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It does not mention side effects, required permissions, or whether the bill status is updated. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the schema covering parameters, the description lacks context on the return value, prerequisites, or how the payment affects the bill. Given the 5-parameter complexity and no output schema, more information is needed for the agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters clearly. The tool description adds no extra meaning beyond what the schema provides, hence baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Record a payment') and the resource ('for a bill'), distinguishing it from sibling tools like wave_create_invoice_payment. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as wave_create_invoice_payment or wave_approve_invoice. No context on prerequisites or exclusions is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new customer
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City | |
| name | Yes | Customer name (company or full name) | |
| No | Email address | ||
| currency | No | Currency code (e.g., USD) | |
| lastName | No | Last name | |
| firstName | No | First name | |
| businessId | No | Business ID | |
| postalCode | No | Postal/ZIP code | |
| countryCode | No | Country code (e.g., US, CA) | |
| addressLine1 | No | Address line 1 | |
| addressLine2 | No | Address line 2 | |
| provinceCode | No | Province/State code (e.g., CA, NY) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It only states 'create', implying mutation, but does not explain what happens on success (e.g., returns the new customer object), error states, idempotency, or side effects. This is insufficient for safe agent decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks structure. It does not front-load key information or separate purpose from usage. While not verbose, it could be more informative without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of creating a customer with 12 parameters and no output schema, the description is incomplete. It does not explain the return value, error handling, or context needed (e.g., that a business must exist). The tool's potential impact is not covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 12 parameters have descriptions in the input schema, so the schema already provides meaning. The description adds no additional parameter-level details, but given 100% coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create' and the resource 'customer', making the basic purpose evident. However, it does not specify what type of customer (e.g., individual vs business) or mention that the tool creates a customer in the context of a business, which leaves some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the many sibling tools like wave_update_customer, wave_search_customers, or wave_list_customers. There is no mention of prerequisites such as needing a business ID or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new estimate (quote)
| Name | Required | Description | Default |
|---|---|---|---|
| memo | No | Internal memo | |
| items | Yes | Estimate line items | |
| title | No | Estimate title | |
| footer | No | Footer text | |
| subhead | No | Estimate subhead | |
| businessId | No | Business ID | |
| customerId | Yes | Customer ID | |
| expiryDate | No | Expiry date (YYYY-MM-DD) | |
| estimateDate | Yes | Estimate date (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. The description only states the action without disclosing side effects (e.g., creation of a new record), required permissions, idempotency, or whether the operation is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one phrase) and front-loaded. However, it could be slightly expanded to include essential context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters including nested items, no output schema, and no annotations, the description is insufficient. It does not explain return values, validation rules, or how parameters interact (e.g., date formats).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. The description adds no extra meaning beyond the schema's parameter descriptions. The schema already provides basic descriptions for all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new estimate (quote)' clearly states the action (create) and the resource (estimate). It distinguishes from sibling tools like wave_get_estimate, wave_list_estimates, and wave_update_estimate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not specify when to use this tool over alternatives such as wave_convert_estimate_to_invoice or wave_send_estimate, nor does it mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new invoice
| Name | Required | Description | Default |
|---|---|---|---|
| memo | No | Internal memo | |
| items | Yes | Invoice line items | |
| title | No | Invoice title | |
| footer | No | Invoice footer text | |
| dueDate | No | Due date (YYYY-MM-DD) | |
| subhead | No | Invoice subhead | |
| businessId | No | Business ID | |
| customerId | Yes | Customer ID | |
| invoiceDate | Yes | Invoice date (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only states 'Create a new invoice' with no mention of side effects, required permissions, idempotency, or what happens after creation (e.g., no output schema). This is insufficient for safe agent invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded with the key action. However, it is too short to provide structured context (e.g., no bullet points or logic flow).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters (3 required) and no output schema, the description is incomplete. It does not explain return behavior, error conditions, or any post-creation effects. The nested items array suggests complexity not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning beyond the schema, which meets the baseline for high coverage but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new invoice' clearly states the action and resource, distinguishing it from update/list/delete siblings. However, it lacks any additional context about scope or special behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like wave_convert_estimate_to_invoice or wave_create_invoice_payment. The description does not specify when it is appropriate or inappropriate to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a payment received for an invoice
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Payment date (YYYY-MM-DD) | |
| amount | Yes | Payment amount | |
| source | No | Payment source/method | |
| invoiceId | Yes | Invoice ID | |
| businessId | No | Business ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without disclosing behavioral traits such as whether it updates invoice status, requires permissions, or is reversible. The description lacks detail beyond the core action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is incomplete. It does not mention what happens after recording (e.g., invoice balance updated, payment ID returned). A more complete description would include side effects or return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with basic descriptions like 'Invoice ID', but the tool description adds no additional meaning. It does not explain relationships between parameters (e.g., how amount relates to invoice balance) or provide context for fields like source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Record' and resource 'payment received for an invoice', making the purpose immediately understandable. It distinguishes from sibling tools like wave_create_invoice (creates invoice) and wave_create_bill_payment (payment for bills) by specifying it's for invoice payments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus similar tools like wave_create_bill_payment or wave_approve_invoice. It does not mention prerequisites (e.g., invoice must exist) or context for using this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new product or service
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Product/service name | |
| isSold | No | Is this product sold to customers? (default: true) | |
| isBought | No | Is this product bought from vendors? (default: false) | |
| unitPrice | No | Default unit price | |
| businessId | No | Business ID | |
| description | No | Product description | |
| incomeAccountId | No | Income account ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states what the tool does without revealing side effects, such as whether creating a product is idempotent, if it triggers any downstream processes, or what permissions are required. The description adds no behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that gets straight to the point with no unnecessary words. However, it could be slightly expanded to include key details about the tool's scope without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema, no annotations), the description is insufficient. It does not explain what happens after creation, such as return values, error conditions, or how the created product is used in the system. The agent lacks crucial context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all 7 parameters, achieving 100% coverage. The description does not add any additional meaning or clarification beyond what the schema offers, so the score is at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new product or service' clearly states the action (create) and the target resource (product or service). It effectively distinguishes this tool from siblings like wave_create_customer or wave_create_invoice, but could be more specific about what constitutes a 'product or service' in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as wave_update_product or wave_delete_product. There is no mention of prerequisites, context, or conditions that would help an agent decide when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new sales tax
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Tax name (e.g., "Sales Tax") | |
| rate | Yes | Tax rate as decimal (e.g., "0.0875" for 8.75%) | |
| businessId | No | Business ID | |
| description | No | Tax description | |
| abbreviation | No | Tax abbreviation (e.g., "ST") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'Create a new sales tax', omitting details on idempotency, required business context, or any side effects. The behavioral traits are minimally disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 words) but lacks structure or additional context. It does not waste words, but is arguably too sparse for a tool with multiple parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity and fully described parameters, the description is adequate but does not mention return values or constraints (e.g., duplicate name handling). It is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 5 parameters. The description adds no additional meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new sales tax' clearly states the action (create) and resource (sales tax), distinguishing it from sibling tools like wave_get_tax, wave_list_taxes, and wave_tax_summary which are for retrieval and reporting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like wave_create_account or wave_create_product, nor are there any prerequisites or constraints mentioned for creating a sales tax.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new transaction
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Transaction date (YYYY-MM-DD) | |
| amount | Yes | Transaction amount | |
| accountId | Yes | Account ID for categorization | |
| businessId | No | Business ID | |
| description | Yes | Transaction description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'create', but does not mention side effects, authentication, or the nature of the transaction (e.g., income vs expense). This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (4 words), but may be too minimal for a tool with 5 parameters. It is front-loaded but lacks necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and the need to distinguish from siblings, the description is insufficient. It does not explain what happens after creation or how this transaction relates to other Wave entities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters have descriptions in the input schema (100% coverage), so the description adds no additional meaning but also does not repeat. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new transaction' clearly states the action and object, but does not differentiate from sibling tools like wave_create_invoice or wave_create_bill, leading to ambiguity about what constitutes a 'transaction' in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as wave_create_invoice or wave_create_bill, nor any prerequisites or context for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a customer (only if they have no invoices)
| Name | Required | Description | Default |
|---|---|---|---|
| businessId | No | Business ID | |
| customerId | Yes | Customer ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the precondition for deletion, which is important behavioral context. However, it does not cover other aspects like error handling, reversibility, or required permissions. With no annotations, more detail would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the essential information without any noise. It is well front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with two parameters and no output schema, the description is largely complete, covering the key precondition. It could be improved by mentioning the response or error behavior, but it is adequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters (businessId and customerId), so the description does not add additional parameter-level semantics. The condition about invoices is about usage context, not parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and the resource 'customer', with a specific condition 'only if they have no invoices'. This distinguishes it from sibling tools like wave_delete_invoice and others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a clear precondition ('only if they have no invoices') that guides when to use this tool. However, it does not provide explicit guidance on when not to use it or suggest alternative tools for cases where the condition is not met.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an invoice (must be in DRAFT status)
| Name | Required | Description | Default |
|---|---|---|---|
| invoiceId | Yes | Invoice ID | |
| businessId | No | Business ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the critical behavioral trait that the invoice must be in DRAFT status. This goes beyond simple 'delete an invoice' and helps the agent understand the constraint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the action and condition. Every word is necessary and no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with a status constraint, the description is reasonably complete. It covers the main precondition. It could mention irreversibility or permissions, but it is adequate given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add any additional meaning beyond the schema's parameter descriptions ('Invoice ID', 'Business ID'). No extra context is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'invoice', and adds a precondition 'must be in DRAFT status'. This distinguishes it from sibling tools like wave_approve_invoice or wave_update_invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes the precondition 'must be in DRAFT status', which tells the agent when to use it. However, it does not explicitly mention alternatives or when not to use it, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete (archive) a product or service
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes | Product ID | |
| businessId | No | Business ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description hints at soft deletion via 'archive', but doesn't clarify whether the action is reversible, what data is affected (e.g., invoices referencing the product), or required permissions. No annotations are provided to fill this gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Exactly one sentence, no wasted words. The key action and outcome are conveyed efficiently. Suitable for a simple deletion operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool without output schema or annotations, the description is too minimal. It lacks information about side effects, reversibility, authorization, and whether the archive is permanent. Given the complexity of business data (products tied to invoices), this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. The description adds no extra meaning beyond the schema: productId and businessId are described only by their names and types. No hints about default behavior, required context, or relationship between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('a product or service'), and includes 'archive' in parentheses to indicate soft deletion. It clearly distinguishes from sibling tools like wave_create_product, wave_list_products, and wave_update_product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., wave_update_product for product adjustments, or wave_create_product for new items). No conditions, prerequisites, or post-effects are mentioned, leaving ambiguity about appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific account
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | Yes | Account ID | |
| businessId | No | Business ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It implies a read operation but does not disclose any behavioral traits beyond that, such as rate limits, auth requirements, or what 'detailed information' entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 9 words, no redundancy, and directly front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description is minimal. It does not explain what 'detailed information' includes or provide any operational context, which is adequate but not complete for complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents both parameters. The description adds no additional meaning beyond what is in the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'account', and specifies 'detailed information' and 'specific account', distinguishing it from other get tools like wave_get_customer or wave_get_invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as wave_list_accounts or other get tools. No context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific bill
| Name | Required | Description | Default |
|---|---|---|---|
| billId | Yes | Bill ID | |
| businessId | No | Business ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for behavioral disclosure. It only states 'get detailed information,' implying a read operation, but does not elaborate on what 'detailed information' includes, permission requirements, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks structure. It could include more details without becoming verbose. Not entirely efficient given missing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description should provide more context about the return value or the scope of 'detailed information.' For a simple get-by-ID tool, the description is barely adequate but fails to fully inform the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters have descriptions: 'Bill ID' and 'Business ID'). The tool description adds no additional meaning beyond these schema descriptions, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get detailed information about a specific bill,' identifying the verb (get) and resource (bill). It implicitly distinguishes from sibling tools like wave_list_bills (list multiple) and wave_create_bill (create), but does not explicitly highlight this distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., wave_list_bills for searching bills). No prerequisites or context about the required billId are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific business
| Name | Required | Description | Default |
|---|---|---|---|
| businessId | Yes | Business ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description only says 'Get detailed information', which implies a read operation. It does not explicitly state it is read-only or non-destructive, but the inference is clear. For a simple GET, this is adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and concise. Every word is necessary, with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is mostly complete. It tells what it does and identifies the input. However, it does not specify the return format, which could be inferred from typical GET behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter 'businessId' described as 'Business ID'. No additional semantic information is needed beyond the schema, so baseline score applies. The description adds no further detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information about a specific business. This differentiates it from siblings like wave_get_current_business (current business without ID) and wave_list_businesses (list all businesses).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool name and parameter imply use when a specific business ID is known. It does not explicitly state when to avoid it, but the context from siblings provides sufficient differentiation. A brief exclusion note would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the currently active business (if businessId is set globally)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Reveals dependency on a global businessId, but lacks detail on error behavior if not set. No output schema or return value description, but annotations are absent, so description carries full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single clear sentence, no unnecessary words, information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple getter tool with no parameters. Could mention what is returned or error state, but overall sufficient given tool simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Description adds no param info, but baseline is 4 due to no params needing explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves the currently active business, with a condition on global businessId. Distinguishes from sibling tools like wave_get_business and wave_list_businesses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly guides when to use (when global businessId is set), but does not explicitly mention alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific customer
| Name | Required | Description | Default |
|---|---|---|---|
| businessId | No | Business ID | |
| customerId | Yes | Customer ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It states the action is a read operation ('Get'), which implies no side effects, but does not explicitly confirm read-only behavior or mention any required permissions or rate limits. Adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that is front-loaded with the key action. No unnecessary words or information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation, the description is functional but lacks detail on what 'detailed information' includes. Without an output schema, the agent may not know what to expect in the response. Could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions ('Business ID', 'Customer ID'). No extra context provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('customer'), and the scope ('detailed information'). It effectively distinguishes from sibling tools like 'wave_list_customers' (list) and 'wave_search_customers' (search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching a single customer's details but lacks explicit guidance on when to use this tool versus alternatives like listing or searching. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific estimate
| Name | Required | Description | Default |
|---|---|---|---|
| businessId | No | Business ID | |
| estimateId | Yes | Estimate ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'Get' implies a read-only operation, but without annotations, the description lacks explicit disclosure of behavioral traits such as safety, side effects, or data volume. Adequate for a simple retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence without unnecessary words. It could be slightly more informative, but it is appropriately concise for a straightforward tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with no output schema, the description is minimally adequate. It could mention that it returns full estimate details, but the current text is sufficient given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. The description does not add any additional meaning or context beyond the parameter names and their brief schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('detailed information about a specific estimate'), distinguishing it from siblings like wave_list_estimates, wave_convert_estimate_to_invoice, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., wave_list_estimates for listing). The description does not provide any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific invoice
| Name | Required | Description | Default |
|---|---|---|---|
| invoiceId | Yes | Invoice ID | |
| businessId | No | Business ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only says 'Get detailed information' which is vague and does not specify read-only nature, authentication requirements, rate limits, or what happens if the invoice does not exist. This is insufficient for an agent to understand side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no fluff. It is front-loaded with the key purpose. However, it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should specify what 'detailed information' includes (e.g., line items, customer details, payment status). Without that, the agent cannot gauge whether this tool meets its needs. The tool is not complete enough for reliable autonomous selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no value beyond the schema's parameter names and descriptions. It does not explain the relationship between parameters (e.g., is businessId needed if user has one business?), nor does it clarify formats or constraints. No extra semantic enrichment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('detailed information about a specific invoice'). It distinguishes from sibling tools like 'wave_list_invoices' which retrieves multiple invoices, and 'wave_approve_invoice' which modifies state. Could be improved by explicitly contrasting with other 'get' tools like 'wave_get_invoice_payment'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., needing the invoice ID from a list operation), no exclusions, and no context about typical workflows. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific product or service
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes | Product ID | |
| businessId | No | Business ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'Get detailed information' without mentioning error handling, auth requirements, output format, or what happens if productId is invalid. The tool's safety profile (read-only) is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. However, it could be expanded to include essential behavioral details without losing conciseness, so it does not achieve a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema, no annotations), the description is incomplete. It does not specify what 'detailed information' includes, nor does it mention any prerequisites or error conditions. An agent would need additional context to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters have descriptions in the schema). The high- coverage baseline is 3; the description adds no additional meaning beyond what the schema already provides for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' and resource 'product or service', clearly distinguishing it from siblings like wave_list_products (list) and wave_create_product (create). It immediately conveys the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as wave_list_products or other get tools. Missing context like 'Use when you have a product ID' or 'Use wave_list_products to find an ID first'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific tax
| Name | Required | Description | Default |
|---|---|---|---|
| taxId | Yes | Tax ID | |
| businessId | No | Business ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It only states 'Get detailed information', implying a read operation, but does not explicitly confirm read-only nature, side effects, authentication needs, or any behavioral traits beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is appropriately front-loaded and easy to read. However, it could include more useful detail without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explain what 'detailed information' returns. It is missing context about the structure of the response, any pagination, or error conditions. For a tool with simple parameters, the description is barely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described ('Tax ID', 'Business ID'). The tool description adds no additional meaning beyond the schema. Baseline for high coverage is 3, and no extra value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed information about a specific tax'. It distinguishes from siblings like wave_list_taxes (listing all taxes) and wave_create_tax (creating taxes). However, it does not specify what 'detailed information' includes, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like wave_list_taxes or wave_create_tax. There is no mention of prerequisites, context for use, or explicit when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific transaction
| Name | Required | Description | Default |
|---|---|---|---|
| businessId | No | Business ID | |
| transactionId | Yes | Transaction ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavioral traits beyond 'Get', such as whether the operation is read-only, what happens if transactionId is invalid, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no unnecessary words. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (get by ID, no output schema), the description is nearly sufficient. Could mention it returns the full transaction object, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already clear. Description adds no extra context beyond what is in the schema, e.g., what 'detailed information' includes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' and resource 'transaction', uniquely identifying the tool among siblings. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like wave_list_transactions. No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all accounts in the chart of accounts
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default: 1) | |
| type | No | Filter by account type (ASSET, LIABILITY, EQUITY, INCOME, EXPENSE) | |
| pageSize | No | Results per page (default: 100) | |
| businessId | No | Business ID | |
| isArchived | No | Include archived accounts (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It only states 'list all accounts' without mentioning pagination, rate limits, or that it is read-only, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. It could be slightly more informative, but it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema or annotations. The description omits details on response format, pagination behavior, and potential performance implications, making it incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameter descriptions are already present. The description adds no additional meaning beyond the schema, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all accounts in the chart of accounts' is a specific verb+resource combination that clearly distinguishes from sibling tools like wave_list_bills or wave_list_customers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor does it specify prefixes or exclusions. A simple statement does not help the agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List payments made for a specific bill
| Name | Required | Description | Default |
|---|---|---|---|
| billId | Yes | Bill ID | |
| businessId | No | Business ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors, but it only states 'list payments'. It does not mention if the operation is read-only, if it supports pagination, ordering, or what happens for invalid bill IDs. The minimal description provides insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, effectively conveying the core purpose without extra words. However, it could benefit from more structure (e.g., bullet points) or examples without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain what is returned (e.g., list of payment objects). It does not. Additionally, it omits any mention of required permissions, rate limits, or other operational context. For a list operation, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with parameter descriptions in the schema ('Bill ID', 'Business ID'). The description adds no additional meaning beyond the schema, so it meets the baseline of 3. No further elaboration on parameter formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists payments for a specific bill, using precise verb 'list' and resource 'payments made for a specific bill'. It is distinct from siblings like wave_list_invoice_payments (invoice payments) and wave_list_bills (bills).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus other list tools. It is implied that it requires a billId, but no alternatives or exclusions are mentioned. For example, it does not contrast with wave_list_invoice_payments or advise against using for invoices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List bills (accounts payable) for a business
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default: 1) | |
| status | No | Filter by bill status | |
| pageSize | No | Results per page (default: 20) | |
| vendorId | No | Filter by vendor ID | |
| businessId | No | Business ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as pagination behavior, authentication needs, rate limits, or whether the operation is read-only. The agent is left to infer behavior from the tool name and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the schema covering parameters, the description lacks context about return values (no output schema), expected behavior, or common use cases. An agent may not have enough information to use the tool effectively in all scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all five parameters, so the description adds minimal value beyond the schema. It does not explain interactions between parameters or provide context beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists bills (accounts payable) for a business, using a specific verb and resource. It distinguishes from sibling tools like wave_list_invoices or wave_list_bill_payments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a parenthetical 'accounts payable' to differentiate from other list tools, but does not include explicit guidance on when to use this tool versus alternatives like wave_list_bill_payments or wave_list_invoices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all businesses accessible with the current access token
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It correctly indicates a read operation but does not disclose details about pagination, return format, or potential limits. For a simple list tool, this is adequate but could be improved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 9 words. It is extremely concise and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and the simplicity of a zero-parameter list operation, the description is nearly complete. It could mention that the output contains business details, but most agents can infer the structure from the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema description coverage is 100%. The description does not need to explain parameters. Baseline score for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all businesses accessible with the current access token. The verb 'list' and resource 'businesses' are explicit. It distinguishes from sibling tools like wave_get_business (single) and wave_get_current_business (current).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to enumerate all accessible businesses. While it does not explicitly state when not to use it or mention alternatives, the context of siblings that retrieve single businesses provides clear differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all customers for a business
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default: 1) | |
| pageSize | No | Results per page (default: 50, max: 100) | |
| businessId | No | Business ID (required if not set globally) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose pagination behavior, rate limits, or cost implications. Listing 'all' customers could be expensive for large businesses, but this is not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but insufficiently informative. It fails to front-load key behavioral details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's three parameters and lack of output schema, the description is too minimal. It does not mention pagination, required business ID, or return format, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes each parameter. The description adds no additional meaning beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (customers), and implies a broad scope (all) which distinguishes it from wave_search_customers. However, it does not explicitly contrast with sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like wave_search_customers or wave_get_customer. The description lacks context about filtering capabilities or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List estimates (quotes) for a business
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default: 1) | |
| status | No | Filter by estimate status | |
| pageSize | No | Results per page (default: 20) | |
| businessId | No | Business ID | |
| customerId | No | Filter by customer ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden. It only states 'list', implying read-only, but fails to mention pagination behavior, default sorting, or empty result handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no redundant information. While it could be enhanced, it is appropriately concise for a straightforward list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description is insufficient. It does not explain return format, pagination details, or the effect of filters, leaving the agent with incomplete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description. The tool description adds no additional semantic value beyond the schema, earning a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'estimates (quotes) for a business', making the tool's purpose unambiguous. However, it does not differentiate from sibling tools like wave_get_estimate, which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as wave_list_invoices or wave_search_customers. The description lacks context on prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List payments received for a specific invoice
| Name | Required | Description | Default |
|---|---|---|---|
| invoiceId | Yes | Invoice ID | |
| businessId | No | Business ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks details about read-only nature, required permissions, rate limits, or error behavior, leaving the agent uninformed about important behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only six words, each contributing to the purpose. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward listing tool, the description is largely complete. However, it omits the optional businessId context and response details, but these are partially covered by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The tool description does not add additional meaning beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List' and the resource 'payments received for a specific invoice', distinguishing it from siblings like wave_list_invoices and wave_create_invoice_payment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (for listing payments of a specific invoice) but does not provide explicit guidance on when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List invoices for a business with optional filtering
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default: 1) | |
| status | No | Filter by invoice status | |
| pageSize | No | Results per page (default: 20, max: 100) | |
| businessId | No | Business ID (required if not set globally) | |
| customerId | No | Filter by customer ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description should disclose behavioral traits like pagination and required businessId. It only says 'with optional filtering', which is insufficient. Does not mention that businessId may be required if not set globally, or that results are paginated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, front-loading the core action. It could include a bit more context (e.g., pagination) without becoming verbose, but is efficient for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description lacks completeness. It does not explain pagination defaults, required businessId context, or the structure of the response list. Sibling tools have similar listings, but this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so description adds minimal value beyond repeating 'list' and 'filtering'. The parameters are well-documented in the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists invoices for a business with optional filtering, distinguishing it from siblings like wave_get_invoice (single invoice) and wave_create_invoice. The verb 'list' and resource 'invoices' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention when not to use it or suggest alternative tools for different scenarios (e.g., retrieving a single invoice).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all products and services for a business
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default: 1) | |
| isSold | No | Filter products that are sold | |
| isBought | No | Filter products that are bought | |
| pageSize | No | Results per page (default: 50) | |
| businessId | No | Business ID | |
| isArchived | No | Include archived products (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states 'List all products and services' without mentioning read-only nature, pagination behavior, or any side effects. Significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words, front-loaded with the action and resource. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no annotations, the description is very minimal. It does not explain return format, pagination, or how to use filters effectively. Incomplete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond what's in the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists products/services for a business. Could be more specific to distinguish from sibling tools like 'get' or 'create', but the verb and resource are clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like wave_get_product or wave_create_product. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all sales taxes configured for a business
| Name | Required | Description | Default |
|---|---|---|---|
| businessId | No | Business ID | |
| isArchived | No | Include archived taxes (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'list all sales taxes', omitting whether it is read-only (implied but not stated), pagination behavior, or required permissions. The optional isArchived parameter is not explained in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded and free of fluff. It earns its place, though it could include more structured information without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, so the description should explain the return value. It does not mention pagination, field coverage, or error handling. For a simple 2-param tool, completeness is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the parameters. The description adds no extra meaning beyond the schema descriptions. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list', the resource 'sales taxes', and the scope 'configured for a business'. It effectively distinguishes from siblings like wave_get_tax (single tax) and wave_create_tax (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., wave_get_tax for a specific tax). No prerequisites or context are mentioned, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List attachments (receipts, documents) for a transaction
| Name | Required | Description | Default |
|---|---|---|---|
| businessId | No | Business ID | |
| transactionId | Yes | Transaction ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'List' implies a read-only operation, but the description does not mention any behavioral traits like authorization needs, error handling, or what happens if the transactionId is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no unnecessary words. It efficiently conveys the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description is adequate but could be more complete by mentioning the expected return format or any constraints. It lacks details like whether attachments include both receipts and documents or other types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with brief descriptions for both parameters. The tool description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'list' and resource 'attachments for a transaction', with examples (receipts, documents). It distinguishes from sibling list tools by focusing on transaction attachments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving attachments of a specific transaction. However, it does not explicitly state when to use this tool versus alternatives like wave_get_transaction or wave_list_transactions, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List transactions for a business with filtering options
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default: 1) | |
| endDate | No | End date (YYYY-MM-DD) | |
| pageSize | No | Results per page (default: 50) | |
| accountId | No | Filter by specific account ID | |
| startDate | No | Start date (YYYY-MM-DD) | |
| businessId | No | Business ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must cover behavioral details. It only states 'list transactions' without disclosing pagination, read-only nature, or any side effects, leaving significant gaps for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, with no unnecessary words. However, it sacrifices informative content for brevity, which is acceptable but not optimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 6 optional parameters and no output schema, the description provides minimal context. It omits expected behavior like pagination, date range handling, and the fact that businessId is likely needed despite being optional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. The description adds 'filtering options' but does not elaborate on parameter relationships or usage constraints beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'List', the resource 'transactions', and the scope 'for a business with filtering options', clearly differentiating it from sibling tools like wave_get_transaction (single transaction) and other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing multiple transactions with filtering, but does not provide explicit guidance on when to use this tool versus alternatives like wave_get_transaction or wave_list_transaction_attachments, nor does it mention prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark an invoice as sent (without actually sending email)
| Name | Required | Description | Default |
|---|---|---|---|
| invoiceId | Yes | Invoice ID | |
| businessId | No | Business ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the key behavior (marks as sent without emailing), but does not elaborate on side effects (e.g., status change, permissions needed, reversibility). Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy. It front-loads the core action and the key qualifier (without sending email). Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no output schema, two parameters), the description is nearly complete. It explains the core behavior, though it could briefly note the effect on invoice status. Still, it provides enough context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds no additional meaning beyond the parameter names listed in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Mark an invoice as sent') and distinguishes from the sibling 'wave_send_invoice' by explicitly noting it does not actually send an email. This provides a specific verb-resource pair with clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when wanting to mark an invoice as sent without email, but does not explicitly state when to use this tool versus alternatives like 'wave_send_invoice' or 'wave_get_invoice'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a Profit & Loss (Income Statement) report
| Name | Required | Description | Default |
|---|---|---|---|
| endDate | Yes | Report end date (YYYY-MM-DD) | |
| startDate | Yes | Report start date (YYYY-MM-DD) | |
| businessId | No | Business ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It only states the action (generate report) but omits important details like whether the operation is read-only, authentication requirements, or side effects. This is insufficient for an agent to understand the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core purpose, though it could benefit from additional details without compromising conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description should explain what the report returns (e.g., data structure, file format). It fails to do so, leaving the agent with incomplete information. The parameter documentation is sufficient, but overall context is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all three parameters, so the baseline is 3. The description does not add additional context beyond what the schema provides, such as how parameters affect the report content or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a Profit & Loss report using a specific verb and resource. While the name and description differentiate it from sibling report tools like balance sheet and cash flow, it does not explicitly distinguish them. However, the resource name is specific enough to convey the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when a balance sheet or cash flow report is more appropriate. It lacks context on prerequisites, usage scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search customers by name or email
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results (default: 20) | |
| query | Yes | Search query (name or email) | |
| businessId | No | Business ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the search criteria without explaining behavior like case sensitivity, fuzzy matching, pagination, or what happens on no results. This is insufficient for an AI agent to fully understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no unnecessary words. It is front-loaded with the key action. However, it is very brief and could benefit from a bit more detail without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the sibling tools and the parameter schema, the description provides enough context to differentiate from listing or getting specific customers. However, the lack of an output schema means the agent does not know the return format, but for a search tool, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for parameters (limit, query, businessId). The tool description adds no additional meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search customers by name or email' clearly states the action (search), resource (customers), and search criteria (name or email). This distinguishes it from sibling tools like 'wave_list_customers' (list all) and 'wave_get_customer' (get specific customer).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a query (name or email) is available, but it does not explicitly state when to use this tool over alternatives like wave_list_customers or wave_get_customer. No 'when to use' or 'when not to use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an estimate to the customer via email
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Recipient email addresses | |
| message | No | Email message body | |
| subject | No | Email subject | |
| businessId | No | Business ID | |
| estimateId | Yes | Estimate ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states the sending action without mentioning side effects (e.g., whether the estimate's status changes to 'sent'), permission requirements, or whether the operation is reversible. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the core purpose. It is appropriately sized for a straightforward tool, though it could benefit from additional context without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and no output schema, the description is too brief. It doesn't clarify email configuration (e.g., whether 'message' and 'subject' override defaults), relationship to the customer's default email, or any confirmation/error feedback. The tool's complexity demands more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 5 parameters. The description adds no extra meaning beyond the schema; it simply says 'to the customer' while the schema allows multiple recipients via 'to' array. This is a minor mismatch, but overall the schema adequately documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Send an estimate to the customer via email' clearly states the action (send), the resource (estimate), and the medium (email). It effectively distinguishes this tool from siblings like 'wave_send_invoice' or 'wave_convert_estimate_to_invoice' by specifying the object and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. There's no indication of prerequisites (e.g., estimate must be in a specific state), when to use this tool vs. alternatives like 'wave_convert_estimate_to_invoice', or any restrictions (e.g., email limits). The agent is left to guess the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an invoice to the customer via email
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Recipient email addresses | |
| message | No | Email message body | |
| subject | No | Email subject | |
| invoiceId | Yes | Invoice ID | |
| businessId | No | Business ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose side effects (e.g., whether the invoice status changes to 'sent', email delivery mechanics, or permission requirements). It only says 'send via email' without explaining the process or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundant words. Appropriate length for a straightforward action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple email action, the description is adequate but could mention prerequisites (e.g., invoice must exist, valid email addresses) or that it may mark the invoice as sent. No output schema means the description should hint at the result, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 5 parameters. The description adds the context that the action is email-sending, but the parameter descriptions in the schema already clearly define each field. No additional meaning beyond schema is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Send an invoice to the customer via email' clearly states the verb (send) and resource (invoice) and specifies the channel (email). It distinguishes from sibling tools like wave_approve_invoice (approve) and wave_mark_invoice_sent (mark as sent without email).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like wave_mark_invoice_sent or wave_create_invoice. The description lacks context for prerequisites or exclusions, such as whether the invoice must already be created or if the customer has email.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a tax summary report for a date range
| Name | Required | Description | Default |
|---|---|---|---|
| endDate | Yes | Report end date (YYYY-MM-DD) | |
| startDate | Yes | Report start date (YYYY-MM-DD) | |
| businessId | No | Business ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It does not state whether the tool is read-only, destructive, requires authentication, or what side effects may occur. As a report generator, it is likely non-destructive, but this is not explicit, leaving ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (8 words, 1 sentence) with no fluff. However, it is so brief that it sacrifices completeness. It could be slightly longer to include critical usage details without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no annotations, the description is incomplete. It fails to specify the report format, content coverage (e.g., sales tax vs. input tax), or any response structure, leaving the agent with insufficient information to handle the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions. The description adds no extra meaning beyond what the schema already provides (e.g., date range). It does not explain the optional businessId parameter, which could be important for multi-business contexts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Generate) and resource (tax summary report), and specifies the key constraint (for a date range). It is specific and distinguishes itself from sibling report tools like wave_balance_sheet or wave_profit_and_loss, though it could be more explicit about what constitutes a tax summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool over other report tools (e.g., wave_aged_receivables, wave_cashflow). It does not mention prerequisites, exclusions, or scenarios where this report is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing account
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Account name | |
| accountId | Yes | Account ID | |
| businessId | No | Business ID | |
| description | No | Account description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is extremely vague, with zero behavioral disclosure. It does not mention whether updates are full replacements or merges, what permissions are needed, or any side effects. No annotations exist to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is very short, it is under-specified for a tool with 4 parameters, no annotations, and no output schema. Conciseness sacrifices essential information, making it insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are 4 parameters, no annotations, and no output schema, the description fails to provide necessary context about success/failure, constraints, or return values. It is not complete enough for an update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the description adds no extra value. Per guidelines, the baseline is 3, and no parameter semantics are provided beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('existing account'), which distinguishes it from creation or deletion tools. However, it lacks nuance about partial updates or idempotency, which could be inferred from the schema but not stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like wave_create_account or wave_get_account. There is no mention of prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing bill
| Name | Required | Description | Default |
|---|---|---|---|
| memo | No | Internal memo | |
| billId | Yes | Bill ID | |
| dueDate | No | Due date (YYYY-MM-DD) | |
| billNumber | No | Bill number | |
| businessId | No | Business ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose important behavioral aspects such as idempotency, partial update behavior, or error conditions. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is concise but could be supplemented with more detail without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description does not explain return values or success/failure indicators. For a mutation tool with no annotations, more context about side effects and prerequisites is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description adds no additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing bill' clearly states the verb (update) and resource (bill), distinguishing it from siblings like wave_create_bill and wave_get_bill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., when to update vs. create a bill). Lacks any context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing customer
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City | |
| name | No | Customer name | |
| No | Email address | ||
| lastName | No | Last name | |
| firstName | No | First name | |
| businessId | No | Business ID | |
| customerId | Yes | Customer ID | |
| postalCode | No | Postal/ZIP code | |
| countryCode | No | Country code | |
| addressLine1 | No | Address line 1 | |
| addressLine2 | No | Address line 2 | |
| provinceCode | No | Province/State code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states the action, omitting side effects, authorization needs, idempotency, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (one sentence) but lacks structure. It is front-loaded with the key action, but could benefit from additional context without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 12 parameters, no output schema, and no annotations, the description is far too minimal. It fails to explain return values, error handling, or any postcondition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds no additional parameter meaning beyond what is already in the schema. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('existing customer'), distinguishing it from create/delete/get customers. However, it does not specify what fields can be updated, though the schema covers that.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like create_customer or delete_customer. No prerequisites or caveats mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing estimate
| Name | Required | Description | Default |
|---|---|---|---|
| memo | No | Internal memo | |
| title | No | Estimate title | |
| footer | No | Footer text | |
| subhead | No | Estimate subhead | |
| businessId | No | Business ID | |
| estimateId | Yes | Estimate ID | |
| expiryDate | No | Expiry date (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It only says 'Update an existing estimate', failing to disclose idempotency, error behavior, permission requirements, or response structure. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise. However, it lacks structural elements like bullet points or additional context that would improve usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description is too minimal. It does not explain the tool's behavior beyond the basic update action, leaving important context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter has its own description. The tool description adds no extra meaning beyond the schema, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'estimate', which distinguishes it from sibling tools like wave_create_estimate or wave_get_estimate. However, it does not specify what fields can be updated, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives (e.g., when to update vs create or convert an estimate). No prerequisites or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing invoice
| Name | Required | Description | Default |
|---|---|---|---|
| memo | No | Internal memo | |
| title | No | Invoice title | |
| footer | No | Invoice footer | |
| dueDate | No | Due date (YYYY-MM-DD) | |
| subhead | No | Invoice subhead | |
| invoiceId | Yes | Invoice ID | |
| businessId | No | Business ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states 'Update an existing invoice' without mentioning permissions, side effects, or whether the update is partial or full, leaving the agent without critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at one sentence, which is efficient but lacks any structure to convey additional useful information. It is neither wasteful nor particularly well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters (1 required) and no output schema. The description is too brief to cover return values, error handling, or success criteria, making it incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond the schema, which meets the baseline expectation of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and resource 'existing invoice', making the tool's purpose clear. However, it does not specify which fields can be updated, leaving ambiguity compared to sibling tools like 'wave_approve_invoice' which have more specific actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'wave_mark_invoice_sent' or 'wave_approve_invoice'. The description lacks any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing product or service
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Product name | |
| productId | Yes | Product ID | |
| unitPrice | No | Default unit price | |
| businessId | No | Business ID | |
| description | No | Product description | |
| incomeAccountId | No | Income account ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'update', implying mutation, but does not explain if partial updates are allowed, what happens to unchanged fields, authorization requirements, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no unnecessary words. However, it could be more informative without being longer, so it is not a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and only one required parameter, the description is minimal. It covers the basic action but does not explain how partial updates work, which fields are commonly updated together, or the expected output. The schema provides good parameter descriptions, but overall completeness for an AI agent is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond 'update', leaving all parameter details to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and the resource 'existing product or service', which distinguishes it from sibling tools like create, delete, get, and list. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when to create a new product instead. No context about prerequisites or scenarios is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing transaction
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Transaction date (YYYY-MM-DD) | |
| businessId | No | Business ID | |
| description | No | Transaction description | |
| transactionId | Yes | Transaction ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'update', implying mutation. With no annotations, the burden is on the description to disclose effects, but it does not specify whether updates are partial or full, required permissions, idempotency, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. It does not prioritize key information or earn its place with additional value beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description fails to explain return values, success conditions, or side effects. For a mutation tool with 4 parameters, more context is needed for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no extra meaning beyond the schema. It does not explain parameter relationships, format constraints, or usage nuances. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing transaction' clearly states the action on a specific resource. It distinguishes from siblings like create, get, list, and categorize transaction tools, but lacks specifics on which fields can be updated or any constraints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like wave_categorize_transaction or wave_create_transaction. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a unique and descriptive name that clearly indicates its target entity and action (e.g., wave_create_invoice, wave_list_customers, wave_delete_product). There is no ambiguity between tools; an agent can easily distinguish them.
All 54 tools follow a consistent verb_noun pattern with the 'wave_' prefix (e.g., wave_create_invoice, wave_get_customer, wave_list_accounts). The naming convention is uniform, making the tool surface predictable and easy to navigate.
54 tools is on the higher end, but it is justified for a comprehensive accounting API covering multiple entities (customers, invoices, bills, products, taxes, transactions) and reports. Each tool serves a distinct purpose, and the count is appropriate for the domain.
Core CRUD and reporting operations are covered for most entities, but there are notable gaps: missing delete for bills, estimates, taxes, and transactions; no update for bill payments; and no delete for taxes. These omissions may hinder some workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server for Mini Accountant: invoices, expenses, customers, analytics, tax estimates.
MCP server for Quaderno — tax-rate calculation, invoices, contacts, products, receipts & expenses.
MCP server for Codat — companies, connections, invoices, bills and financial statements.
MCP server for Autumn — read customers, plans, balances & invoices; track usage and attach plans.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mvicari/wave-mcp-remote'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
