A public, read-only Model Context Protocol server that lets AI agents answer questions about HelloBooks accurately — pricing, integrations, country support, compliance frameworks — instead of relying on stale web snippets.
This is the public server. It exposes only marketing-derived, public-domain data. The authenticated MCP server that reads a customer's books lives in
AI-MCP-Hellobooks.
claude mcp add --transport http hellobooks https://agents.hellobooks.ai/mcpOr, for local development:
claude mcp add hellobooks-local node /path/to/HelloBooks-MCP-Public/dist/stdio.jsRelated MCP server: penni-mcp
Tool | Description |
| All HelloBooks plans (Free, Pro, Business, CPA) + Warehouse / Manufacturing add-ons. Optional |
| Banks, payments, payroll, time tracking, shipping, tax-compliance, accounting sync, ecommerce, CRM, storage (Drive/OneDrive), freelance (Upwork). Optional |
| Per-country feature availability (BAS, STP, GST e-invoice, MTD, 1099, etc.). |
| For a given country, the supported compliance frameworks with version + cert info. |
| Competitor positioning (QuickBooks, Xero, FreshBooks, Wave, Zoho Books, Tally) with where HelloBooks wins, where the competitor wins, and pricing notes. Optional |
| When statutory returns and payroll filings are due, per country. Covers IN (GSTR-1/3B/9/9C, CMP-08, Form 24Q, Form 16, PF ECR, ESI), AU (BAS, STP, Super Guarantee), GB (VAT MTD, RTI, Self Assessment), US (1099-NEC/MISC, W-2, Form 941/940), CA (T4, GST/HST). Optional |
| Local bank-rail / wallet payment methods (UPI, BACS, PayID, BPAY, ACH, RTP, Zelle, PayNow, FAST, Interac, …) with rail speed, use-cases, authority, and HelloBooks support level. Optional |
| Free-text search across the marketing feature catalog, plan features, integrations, country features, compliance frameworks, competitor positioning, statutory deadlines, local payment methods, and published articles. Queries like |
| Full 96-feature marketing catalog. Filter by |
| The 13 feature categories on the marketing site with per-category counts by status (live/beta/planned). |
| Published content on hellobooks.ai — head-to-head compare pages and curated flagship blog posts. Optional |
| Statutory tax-rate slabs by jurisdiction — IN GST (5/12/18/28 + zero + exempt + composition trader/manufacturer/restaurant), UK VAT (20/5/zero/exempt), AU GST (10/GST-free), US state-administered summary, CA GST + HST (ON, Atlantic), SG GST 9%, NZ GST 15%, AE VAT 5%. Filter by |
| Pick a single statutory rate by exact |
URI | Description |
| Markdown product summary. |
| Recent release notes as JSON. |
| Full marketing feature catalog (96+ features across 13 categories) as JSON. |
Read-only by construction. No tool mutates state. No tool reaches a customer system.
Public data only. All catalog content is sourced from the public marketing site.
No authentication. Intentional — this is a knowledge endpoint.
Rate-limited. 120 req/min per IP, 60 req/min per session.
Audit gate. npm run audit:public-data blocks deploys if any PII / auth token strings appear in src/data/.
npm install
npm run dev # HTTP server on :8080 with watch mode
npm run dev:stdio # stdio transport for local MCP client testing
npm test # node:test runner
npm run build
npm run audit:public-datasrc/
data/ # Static catalogs — plans, integrations, countries, articles, about
tools/ # One file per MCP tool
resources/ # MCP resource registry
server.ts # MCP server factory (wires tools + resources)
http.ts # Streamable HTTP transport with rate limiting
stdio.ts # stdio transport entry point
test/
tools.test.ts
resources.test.ts
public-data.test.ts # Audit gate
scripts/
audit-public-data.ts # CI-callable auditContainerised — see Dockerfile. Designed to run behind a TLS-terminating load balancer.
Set PORT and HOST via environment.
Optional anonymous usage telemetry (Layer-2 server-side analytics) is sent to GA4 via
the Measurement Protocol when GA4_MEASUREMENT_ID and GA4_API_SECRET are both set —
see .env.example and src/analytics.ts. Leave them unset and the server runs with
telemetry fully disabled. No customer data, request bodies, tool-argument values, or
IP addresses are ever sent — only anonymous counts. See strategy doc 73.
docker build -t hellobooks-mcp-public .
docker run -p 8080:8080 hellobooks-mcp-publicListed in the MCP registry.
Linked from the marketing site footer and /mcp page.
Referenced in https://hellobooks.ai/llms.txt.
MIT — see LICENSE.
Take a Balance Sheet CSV export from QuickBooks Online, Xero, Zoho Books, or Wave (source auto-detected) and run three checks: (1) bs.equation_broken — the fundamental accounting equation Assets = Liabilities + Equity does not hold (every downstream ratio analysis is invalid until fixed); (2) bs.negative_asset — Cash / AR / Inventory line items with negative balances (reconciliation error signal); (3) bs.negative_equity — Total Equity < 0 (insolvency signal). Input is raw CSV text of a Balance Sheet (Reports → Balance Sheet in QBO / Xero / Zoho / Wave). Max 5,000 rows; max 5 MB. Returns flags with severity, totals (totalAssets, totalLiabilities, totalEquity, equationBalances boolean), and a shareable URL. Use this when a user pastes a Balance Sheet and asks "does my balance sheet balance?", "is the accounting equation satisfied?", or "is my company solvent on paper?". A Balance Sheet that fails Assets = Liabilities + Equity invalidates every downstream financial-ratio analysis — this is the single most important check for any BS.
| Name | Required | Description | Default |
|---|---|---|---|
| csvText | Yes | Raw CSV text of a Balance Sheet report. Works with QuickBooks Online (Reports → Balance Sheet), Xero (Reports → Balance Sheet), Zoho Books (Reports → Balance Sheet), and Wave (Reports → Balance Sheet). Statement should include Total Assets, Total Liabilities, and Total Equity rows. Source is auto-detected from section name signatures. | |
| fileName | No | Optional filename for the share-page label. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: input format (CSV), sources, row/size limits, three check definitions, output fields (flags, totals, URL), and the critical implication that a failed equation invalidates downstream ratios.
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 well-structured with a clear list of checks, input specs, output description, and use cases. It is slightly long but each sentence adds value; minor redundancy in the importance statement.
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 (3 checks, multiple sources), the description covers inputs, constraints, outputs, and use cases adequately. Without an output schema, it still explains return values (flags, totals, URL). It could detail flag severity, but is sufficient.
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 both parameters. The description adds context beyond schema: for csvText it specifies required rows (Total Assets, etc.) and source auto-detection; for fileName it notes optional label for share page.
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 takes a Balance Sheet CSV and runs three specific checks (equation, negative asset, negative equity), with source auto-detection. It distinguishes from sibling tools by focusing on balance sheet-specific checks and notes it's the most important check for any BS.
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 explicitly says 'Use this when a user pastes a Balance Sheet and asks...' and gives three example questions. It could mention alternatives like analyze_profit_loss for income statements, but the use cases are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two periods of journal-entry data (QBO or Xero — source auto-detected from headers) and flag accounts whose movement deviates materially between periods. Aggregates lines per account into a net total for each period, then surfaces accounts where the period-over-period change crosses a materiality threshold (≥5% relative AND ≥$100 absolute; severity high at ≥50%, medium at ≥20%, low at ≥5%). Inputs are two CSV exports — periodACsv (earlier period) and periodBCsv (later period). Optional periodALabel / periodBLabel for human-readable flag messages (e.g. "Q1 FY2024" vs "Q2 FY2024"). Max 5,000 rows per period; max 5 MB each. Use this when a user pastes two periods and asks "what changed?", "show me variances", "what jumped period-over-period". Returns a flag list ordered by largest delta, a roll-up, and a shareable URL. Both periods must be the same source — mixing QBO + Xero in one call returns an error.
| Name | Required | Description | Default |
|---|---|---|---|
| periodACsv | Yes | Raw CSV text of the EARLIER period's journal-entry export (QBO Journal Entries or Xero Manual Journals). Source is auto-detected from the headers. | |
| periodBCsv | Yes | Raw CSV text of the LATER period's journal-entry export. Source is auto-detected from the headers (must match periodACsv). | |
| periodALabel | No | Optional human label for the earlier period — e.g. "Q1 FY2024". Used in flag messages. | |
| periodBLabel | No | Optional human label for the later period — e.g. "Q2 FY2024". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes aggregation, threshold logic (≥5% relative and ≥$100 absolute with severity levels), output format (flag list, roll-up, shareable URL), and error condition (mixing sources). Without annotations, it covers key behaviors well, though no mention of read-only/destructive nature.
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?
Front-loaded with purpose, then detailed constraints and logic. Every sentence contributes value; slight redundancy in source-matching requirement but overall 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?
Given complexity (two CSVs, auto-detection, threshold logic, no output schema), description covers input requirements, processing, output format, and error conditions thoroughly. No gaps evident.
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%, but description adds crucial semantics: clarifies earlier vs later period, auto-detection, max sizes, optional labels for human readability. Adds value beyond 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?
Clearly states the tool compares two periods of journal-entry data and flags accounts with material variance. Differentiates from sibling tools like anomaly detection or cleanup tools by focusing on period-over-period variance for both QBO and Xero.
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?
Provides explicit use cases (e.g., 'what changed?', 'show me variances') and constraints (max rows/size, source matching). Lacks explicit 'do not use when' statements but gives strong positive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a Profit & Loss / Income Statement CSV export from QuickBooks Online, Xero, Zoho Books, or Wave (source auto-detected from section names) and run three checks: (1) pnl.subtotal_mismatch — each "Total Section" subtotal equals the sum of its preceding line items (catches missing or duplicated rows); (2) pnl.negative_expense — flags expense-section line items with negative amounts (usually sign-flips or refunds posted to the wrong side); (3) pnl.margin_red_flag — gross-profit margin < 5% or > 95%, or negative total revenue. Input is raw CSV text of a P&L report (Reports → Profit and Loss in QBO / Xero / Zoho / Wave). Max 5,000 rows; max 5 MB. Returns flags with severity, a summary with totalRevenue / totalCogs / grossProfit / grossMarginPct / netIncome (when detected), and a shareable URL at agents.hellobooks.ai/r/{slug}. Use this when a user pastes a P&L and asks "does my P&L look right?", "any sign errors?", "what is my gross margin?", or "anything suspicious in my income statement?". For period-over-period comparison use analyze_journal_variance with two periods of journal-entry data; this tool is single-period only.
| Name | Required | Description | Default |
|---|---|---|---|
| csvText | Yes | Raw CSV text of a Profit & Loss / Income Statement report. Works with QuickBooks Online (Reports → Profit and Loss), Xero (Reports → Profit and Loss), Zoho Books (Reports → Profit & Loss), and Wave (Reports → Profit & Loss). Source is auto-detected from section names. Statement should include section headers, line items, "Total X" subtotals, and a Net Income / Net Profit row at the bottom. | |
| fileName | No | Optional filename for the share-page label. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It details the three checks, the output format (flags with severity, summary with fields, shareable URL), and input limits (max 5000 rows, 5 MB). It does not explicitly state that the tool is read-only or non-destructive, but this is implied by the nature of analyzing CSV text.
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 well-structured and front-loaded with the tool's purpose and checks. It is relatively long but every sentence adds value, including usage examples and alternative tool reference. Could be slightly more concise but remains clear.
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 (three checks, multiple sources, auto-detection), the description covers input format, output fields, limits, and alternative usage. No output schema exists, so the description adequately explains return values (flags, summary, URL) and usage 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?
With schema description coverage at 100%, baseline is 3. The description adds meaning beyond the schema for csvText by specifying supported sources (QuickBooks, Xero, etc.) and required structure (section headers, subtotals, net income row). For fileName, it repeats the schema description.
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 that the tool takes a P&L CSV and runs three specific checks (subtotal mismatch, negative expense, margin red flag). It distinguishes itself from the sibling tool analyze_journal_variance by noting that tool is for period-over-period comparison, while this is single-period.
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 explicitly provides usage scenarios: 'Use this when a user pastes a P&L and asks...' and gives example user queries. It also tells when not to use it, directing to analyze_journal_variance for period-over-period comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a QuickBooks Online "Journal Entries" CSV export for anomalies — currently round-number lines (debit or credit amounts that are exact multiples of $1,000, above a $1,000 materiality threshold). Round numbers are statistically rare in real bookkeeping and frequently indicate estimates, plugs, or fraud signals worth review. Input is raw CSV text from QBO Reports → Accountant → Journal. Max 5,000 rows; max 5 MB. Returns flagged lines with severity ($100K+ high, $10K+ medium, else low) and a shareable URL. Use this when a user pastes QBO data and asks "any anomalies?", "look for round numbers", or "anything suspicious". Tier-0 subset — HelloBooks Phase 3.0 anomaly detection in the paid product additionally catches GL outliers vs entity history, vendor-history mismatches, archived-vendor activity, and AI-narrated suspicious lines (which require the live HelloBooks account).
| Name | Required | Description | Default |
|---|---|---|---|
| csvText | Yes | Raw CSV text of a QuickBooks Online "Journal Entries" report. Export from QBO: Reports → Accountant → Journal → Export as CSV. Paste the file contents directly. | |
| fileName | No | Optional original filename, used only as a label on the share page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: input format (raw CSV text from QBO Reports → Accountant → Journal), limits (max 5,000 rows, 5 MB), output (flagged lines with severity and a shareable URL), and what the tool does not do (paid product features). No contradictions.
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 well-structured and front-loaded with the core purpose. Every sentence adds value—input details, use cases, limitations, and relation to paid features. No redundant or wasted words.
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 anomaly detection and absence of an output schema, the description is remarkably complete. It covers input, output, use cases, limits, severity levels, and ties to the product roadmap, leaving no critical 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 description coverage is 100%, so baseline is 3. The description adds context beyond the schema by explaining the expected CSV format and the purpose of the optional fileName as a label. This extra information raises the score slightly.
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 scans a QBO Journal Entries CSV for anomalies, specifically round-number lines. It distinguishes itself from sibling tools like analyze_xero_journal_anomalies and analyze_qbo_journal_cleanup by specifying the exact input source and type of anomaly.
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?
Explicitly mentions when to use: when a user pastes QBO data and asks 'any anomalies?', 'look for round numbers', or 'anything suspicious'. It also clarifies this is a Tier-0 subset and that the paid product has additional capabilities, providing clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a QuickBooks Online "Journal Entries" CSV export for cleanup issues — unbalanced journals (debits ≠ credits, with severity by deviation), duplicate journals (same date + same totals, likely posted twice), and schema problems (invalid dates, malformed amounts, missing accounts, missing journal numbers). Input is the raw CSV content the user pastes after exporting from QBO via Reports → Accountant → Journal → Export. Max 5,000 rows; max 5 MB. Returns a structured flag list with severity (high/medium/low), a roll-up summary by category and severity, parse diagnostics (column mapping + unmapped columns), and a shareable URL at agents.hellobooks.ai/r/{slug} (7-day TTL) that renders a branded analysis page suitable for sending to a CA or bookkeeper. Use this when a user pastes QBO journal data, asks "check my books", "find issues in my QBO journal", or "what is wrong with my journal entries". Each flag includes a fixableInHellobooks boolean — true means HelloBooks can resolve it automatically in the paid product.
| Name | Required | Description | Default |
|---|---|---|---|
| csvText | Yes | Raw CSV text of a QuickBooks Online "Journal Entries" report. Export from QBO: Reports → Accountant → Journal → Export as CSV. Paste the file contents directly. | |
| fileName | No | Optional original filename, used only as a label on the share page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses input limits, output structure, and shareable URL with TTL. However, it does not explicitly state the tool is read-only or has no 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?
Description is detailed and informative but somewhat long. Every sentence adds value, though it could be slightly more compact without losing clarity.
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?
Fully covers what the tool does, when to use it, input requirements, output breakdown (flags, summary, diagnostics, shareable URL), and limits (5000 rows, 5MB). No output schema, so description compensates well.
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?
Both parameters are described in schema with 100% coverage. Description adds context: how to obtain the CSV (QBO export path), max size constraints, and the purpose of fileName as a label.
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 specifies the exact actions: scanning QBO journal CSV for unbalanced, duplicate, and schema issues. It clearly distinguishes from siblings by naming QBO cleanup and listing specific categories.
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?
Explicitly states when to use: when user pastes QBO journal data and asks specific queries like 'check my books' or 'find issues'. Implicitly excludes Xero-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a Trial Balance CSV export from QuickBooks Online, Xero, Zoho Books, or Wave (source auto-detected from headers — YTD columns indicate Xero, Opening Balance indicates Zoho, etc.) and run three checks: (1) tb.unbalanced — debits ≠ credits (every downstream P&L / BS / cash-flow report built from this TB is wrong until fixed); (2) tb.wrong_sign — accounts whose name suggests a class (Revenue / COGS / Expense / AR / AP) carrying a balance on the wrong side (classic posting-error signal); (3) tb.round_balance — exact-multiple-of-$10,000 balances (plug-entry signal). Input is raw CSV text of a Trial Balance report. Max 5,000 rows; max 5 MB. Returns flagged accounts with severity, a roll-up showing whether the TB balances, parse diagnostics, and a shareable URL at agents.hellobooks.ai/r/{slug}. Use this when a user pastes a Trial Balance and asks "does my TB balance?", "are there sign errors?", "what looks suspicious?", or "is this TB clean?". The Trial Balance is the foundation document for every other financial statement — if it does not balance, every downstream report is invalid.
| Name | Required | Description | Default |
|---|---|---|---|
| csvText | Yes | Raw CSV text of a Trial Balance report. Works with QuickBooks Online (Reports → Trial Balance), Xero (Reports → Trial Balance), Zoho Books (Reports → Accountant → Trial Balance), and Wave (Reports → Trial Balance). Source is auto-detected from column headers. | |
| fileName | No | Optional filename for the share-page label. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: auto-detection of CSV source from headers, max rows/ size limits, the three checks performed, and the returned data (flagged accounts, severity, roll-up, diagnostics, shareable URL). It also warns about downstream report invalidity if the TB is unbalanced.
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 relatively long but well-structured: it starts with the tool's purpose, lists the checks, specifies input constraints, and describes output. Every sentence provides essential information; however, it could be slightly more concise without losing clarity.
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 adequately explains the return values (flagged accounts with severity, roll-up, diagnostics, shareable URL) and input limits. It lacks exact output structure details, but the summary is sufficient for an agent to understand what to expect.
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 both parameters. The description adds significant value beyond the schema by explaining how csvText is used (raw CSV from specific sources), the auto-detection logic, the three checks, and that fileName is optional for a share-page label.
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 ('analyze') and resource ('Trial Balance CSV') and clearly distinguishes the tool from sibling tools by detailing the three specific checks (unbalanced, wrong sign, round balance) and listing supported accounting software. No sibling tool covers trial balance validation.
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 explicitly states when to use the tool: 'when a user pastes a Trial Balance and asks...' and provides example queries. It does not explicitly mention when not to use it or suggest alternative tools for other financial statements, but the context is clear enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a Xero "Manual Journals" CSV export for anomalies — currently round-number lines (debit or credit amounts that are exact multiples of $1,000, above a $1,000 materiality threshold). Input is raw CSV text from Xero Accounting → Advanced → Manual Journals → Export. Max 5,000 rows; max 5 MB. Returns flagged lines with severity ($100K+ high, $10K+ medium, else low) and a shareable URL. Use this when a user pastes Xero data and asks "any anomalies?", "look for round numbers", or "anything suspicious". Same Tier-0 / paid-product split as the QBO variant — history-aware anomaly checks (GL outliers, vendor history, archived-vendor activity, LLM-narrated suspicious) live in the authenticated MCP / paid product.
| Name | Required | Description | Default |
|---|---|---|---|
| csvText | Yes | Raw CSV text of a Xero "Manual Journals" report. Export from Xero: Accounting → Advanced → Manual Journals → Export. Paste the file contents directly. | |
| fileName | No | Optional original filename, used only as a label on the share page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: input is raw CSV, max 5,000 rows/5 MB, returns severity-labeled flagged lines and a shareable URL. It also clarifies the scope (only round-number anomalies) and product tier.
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 thorough and front-loaded with the main purpose, but it includes some longer sentences that could be slightly more concise. Overall, it is 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 description covers input format, size limits, output structure, and product context, making it complete for an anomaly-detection tool without an output 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 coverage is 100%, so the baseline is 3. The description adds minimal semantic value beyond the schema: it restates the CSV source but does not elaborate on the fileName parameter's use.
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 scans Xero Manual Journals CSV for round-number anomalies, specifying the threshold and output format. It distinguishes from sibling tools by mentioning the QBO variant and the split between unauthenticated and authenticated checks.
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 explicit context for when to use the tool (e.g., user asks 'any anomalies?') and notes that advanced history-aware checks are in the paid product, but it does not explicitly list 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.
Scan a Xero "Manual Journals" CSV export for cleanup issues — unbalanced journals, duplicate journals (same date + same totals), and schema problems (invalid dates, malformed amounts, missing account code/name, missing group key). Input is the raw CSV content the user pastes after exporting from Xero via Accounting → Advanced → Manual Journals → Export. Xero-specific idioms handled: signed Amount column (positive = credit, negative = debit), explicit Debit/Credit fallback shape, Reference-or-Narration+Date grouping, account code preferred over name. Max 5,000 rows; max 5 MB. Returns structured flags with severity, a roll-up summary, parse diagnostics, and a shareable URL at agents.hellobooks.ai/r/{slug}. Use this when a user pastes Xero manual-journal data, asks "check my Xero books", or "find issues in my Xero journal". The funnel CTA routes to /migrate/from-xero for users who want to fix at scale.
| Name | Required | Description | Default |
|---|---|---|---|
| csvText | Yes | Raw CSV text of a Xero "Manual Journals" report. Export from Xero: Accounting → Advanced → Manual Journals → Export. Paste the file contents directly. | |
| fileName | No | Optional original filename, used only as a label on the share page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully covers behavior: Xero-specific idioms (signed Amount, Debit/Credit, Reference/Narration grouping), limits (5,000 rows, 5 MB), output structure (flags, summary, diagnostics, URL), and funnel CTA.
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?
Every sentence earns its place: purpose, input source, idioms, constraints, output, use case, CTA. Well organized and front-loaded with main 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?
Covers all necessary aspects: input format, behavioral details, output summary, and usage case. No output schema, but description explains return values sufficiently.
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%, but description adds crucial context: input is raw CSV from specific Xero export, fileName is optional label. Explains what the CSV contains and how to obtain 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?
States exactly what the tool does: scan Xero 'Manual Journals' CSV export for cleanup issues (unbalanced, duplicate, schema). Distinct from sibling QBO or anomaly tools by specifying Xero and cleanup focus.
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?
Explicitly says when to use (user pastes Xero manual-journal data, asks check/find issues). Gives exact export path. Does not explicitly exclude alternatives, but 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.
Take a QBO or Xero journal-entry CSV (source auto-detected), run the full Tier-0 detection set (imbalance + duplicates + round-number + schema), and return a structured side-by-side comparison — "your books have X issues; here is how HelloBooks resolves each phase". This is the direct funnel tool: the response includes per-category counts mapped to HelloBooks Phases 1, 2, 3.0, 3.1, with exclusive-advantage bullets (command-center dashboard, conversational interface, one-prompt JE posting, cross-phase orchestration, auto ID resolution). Use this when a user is evaluating HelloBooks vs their current QBO/Xero, asks "should I migrate?", or pastes data while comparing accounting software. Output is suitable for the host LLM to narrate as a positioning argument; the share URL points at a branded landing page with the issue breakdown and a 1-click migrate CTA.
| Name | Required | Description | Default |
|---|---|---|---|
| csvText | Yes | Raw CSV text of a journal-entry export from QBO ("Journal Entries") or Xero ("Manual Journals"). Source is auto-detected from the headers. | |
| fileName | No | Optional filename label. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool auto-detects the source, runs multiple detection sets, and returns a structured comparison with per-category counts and advantage bullets. It does not mention side effects, but the tool appears to be a read-only analysis. Minor gap: no explicit statement of non-destructiveness or error handling for invalid input.
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 well-structured with three sentences: core function, use case, and output/appropriateness. It is front-loaded with the action. While somewhat long, each sentence adds distinct value, making it 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 no output schema, the description thoroughly explains the output structure (per-category counts, phases, exclusive-advantage bullets, share URL). It covers input, processing, output, and use case, providing complete context for an agent to select and invoke the tool 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% with clear parameter descriptions for csvText and fileName. The tool description adds value by explaining the purpose of the CSV, auto-detection, and the mapping of results to HelloBooks phases, which goes beyond 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's purpose: taking a QBO or Xero journal-entry CSV, running a detection set (imbalance, duplicates, etc.), and returning a structured side-by-side comparison. It specifies the output includes per-category counts mapped to HelloBooks phases and exclusive-advantage bullets, distinguishing it from sibling analysis 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 explicitly says when to use: when a user is evaluating HelloBooks vs QBO/Xero, asks about migration, or pastes data for comparison. It notes the output is suitable for the host LLM to narrate as a positioning argument. However, it lacks explicit when-not-to-use guidance, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return supported compliance frameworks for a country (BAS, STP, GST, MTD, 1099, etc.) with version and certification info.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Required ISO country code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Return' suggests a read-only operation, but it does not explicitly declare the tool as safe or idempotent. It also omits details like authorization needs 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, well-structured sentence that front-loads the verb 'Return' and concisely conveys the tool's purpose and output details without any 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?
Given the tool's simplicity (one parameter, no output schema), the description covers the core purpose and output nature. However, it could be more complete by specifying the exact structure of the returned data (e.g., list of frameworks with fields like name, version, certification).
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% for the single required parameter 'country' (ISO code with enum). The description adds value by listing example frameworks (BAS, STP, etc.) that are associated with each country, providing context beyond the enum values.
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 returns supported compliance frameworks for a given country, listing examples (BAS, STP, etc.) and mentions version/certification info. This differentiates it from siblings like compliance_deadlines or country_support.
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 this tool (to retrieve country-specific compliance frameworks) but does not explicitly state when not to use it or mention alternatives. It is clear within the context of siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
When statutory returns and payroll filings are due, per country. Covers IN (GSTR-1/3B/9/9C, CMP-08, Form 24Q, Form 16, PF ECR, ESI), AU (BAS, STP, Super Guarantee), GB (VAT MTD, RTI, Self Assessment), US (1099-NEC/MISC, W-2, Form 941/940), CA (T4, GST/HST). Optional country, frequency, and form filters. Note: dates rotate annually — every response carries a disclaimer with the per-deadline source URL for authority confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ISO country code. Filters to one country (IN, AU, GB, US, CA covered today). | |
| frequency | No | Filing cadence. Useful for "what are my monthly returns" style queries. | |
| form | No | Substring match against form name, e.g. "GSTR-3B", "BAS", "1099", "T4". Case-insensitive. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses that dates rotate annually and that responses include a disclaimer with source URLs for authority confirmation. It also lists covered forms, offering good transparency. Missing details on return format or error handling prevent a 5.
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 (3 sentences) and front-loaded with the main purpose. Every sentence adds useful information without 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?
Given the tool has 3 optional parameters and no output schema, the description adequately explains what the tool returns (deadlines with source URLs) and the filter options. It covers the key aspects, though timezone or date format details would add completeness.
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%, but the description adds value by providing concrete examples (e.g., 'GSTR-3B', 'BAS') and explaining the purpose of each filter. This goes beyond the schema's generic 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 tool's purpose: 'when statutory returns and payroll filings are due, per country.' It lists specific countries and forms, and distinguishes from siblings like list_tax_rates or compliance_capabilities by focusing on deadlines.
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 usage context by listing optional filters (country, frequency, form) and noting that dates rotate annually. However, it does not explicitly state when to avoid this tool or mention alternatives, which prevents a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return features available per supported country (AU, IN, UK, US, CA, AE, SG, NZ).
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Single ISO country code. Omit for the full matrix. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only says 'Return features', implying a read operation, but does not disclose any behavioral traits such as idempotency, rate limits, or return format. For a simple read tool, this minimal transparency is a 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?
The description is a single sentence with no wasted words. It front-loads the key information: what the tool does and the supported countries. Ideal conciseness for a simple lookup 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?
Given the tool's simplicity (1 optional param, no output schema), the description is adequate but lacks details about the return format or possible errors. The mention of 'full matrix' in the schema is not in the description. More completeness would be beneficial, but the tool is straightforward.
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% (parameter has a description: 'Single ISO country code. Omit for the full matrix.'). The description adds the list of supported countries, which is marginally helpful but does not add new semantics beyond 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 verb 'Return', the resource 'features available per supported country', and lists the specific country codes. It distinguishes this tool from siblings like 'compliance_capabilities' which likely return compliance-related data rather than general features.
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., compliance_capabilities). The description does not specify when not to use it or mention any preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a QBO or Xero journal-entry CSV (source auto-detected) and return a structured migration-effort estimate — row counts, unique-account count, period span, complexity classification (low / medium / high), human-hours estimate, assisted-hours estimate, and an indicative price quote in USD. Heuristic-based — refined against the live entity once the user signs up. Accepts larger files than the other analytical tools (up to 50,000 rows / 20 MB) because no detection runs here, just sizing. Use this when a user is weighing the cost of moving books to HelloBooks, pastes data and asks "how long will migration take?", "what would this cost?", or "is it worth migrating?". The funnel CTA points at /migrate/?ref= to start the assisted flow with the parsed sizing pre-populated.
| Name | Required | Description | Default |
|---|---|---|---|
| csvText | Yes | Raw CSV text of a journal-entry export from QBO ("Journal Entries") or Xero ("Manual Journals"). Source is auto-detected from headers. | |
| fileName | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses heuristic-based behavior, refinement upon signup, and larger file limits. However, it does not explicitly state that it is read-only or non-destructive, which would be helpful given the absence of annotations.
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 reasonably concise with three substantive sentences. It is front-loaded with the main purpose and adds useful details. The final sentence about the funnel CTA is slightly tangential but still relevant for context.
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 2 parameters and no output schema, the description thoroughly covers the output structure (row counts, account count, complexity, hours, price quote) and explains the heuristic approach. It is complete for a sizing tool, though it could mention error handling for invalid CSVs.
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 has 2 parameters (csvText required, fileName optional) with 50% description coverage (only csvText described). The description adds meaning by explaining source auto-detection and file size constraints, but does not describe the fileName parameter, leaving it under-specified.
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 tool takes a QBO or Xero journal-entry CSV and returns a structured migration-effort estimate with specific metrics like row counts, unique accounts, and complexity classification. It is distinct from sibling analysis 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 explicitly states when to use: when a user is weighing migration cost, asks about time or cost, or asks if it's worth migrating. It also notes larger file acceptance. However, it does not explicitly list when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free-text search across the marketing feature catalog, plan features, integrations, country features, compliance frameworks, competitor positioning, statutory deadlines, local payment methods, and published articles on hellobooks.ai. Queries like "vs Xero", "QuickBooks alternative", "GSTR-3B due", "UPI invoice", "1099 article", or "agentic accounting" surface the matching entry near the top.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Free-text query, e.g. "BAS lodgement", "multi-currency", "vs QuickBooks", "GSTR-3B due", or "UPI invoice cap". | |
| limit | No | Max results to return (default 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that matching entries appear 'near the top', implying ranking, but does not specify search algorithm (e.g., fuzzy vs exact), result format, or whether it requires authentication. Adequate but not detailed.
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 paragraph that front-loads the scope of search and immediately follows with concrete examples. Every sentence is informative with no redundancy.
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 search tool with no output schema, the description adequately explains what is searched and gives sample queries. It could mention that results are ordered by relevance or how the limit parameter affects pagination, but overall it provides sufficient 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%, both parameters already have descriptions. The description adds value by providing realistic example queries for the 'query' parameter, helping agents understand the range of inputs. No extra detail for 'limit' beyond 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 it is a free-text search across many specific catalogs (marketing features, plans, integrations, etc.) and provides multiple example queries, making its purpose distinct from sibling list or analysis 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 this tool should be used for broad, semantic queries (e.g., 'vs Xero', 'GSTR-3B due') rather than exact list lookups. It does not explicitly exclude cases, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain how HelloBooks and Munimji (the in-app AI assistant) help a specific business — given a free-text description of the user's own operations. Returns a curated capability knowledge base: business-operation areas (sales, purchases, banking, tax, reports, inventory, payroll, multi-entity, setup), and for each AI capability WHO does the work — autonomous (Munimji does it on its own, e.g. OCR extraction, running reports), approval (Munimji prepares the entry and you one-click approve before it posts to the ledger, e.g. AI categorization, find-and-match, creating invoices/bills by chat), assist (co-pilot, e.g. guided onboarding, voice), or manual (a software feature you run yourself). Each capability links to the backing software features. Use this when a user describes their business and asks "how can HelloBooks help me?", "what can the AI do for my shop/practice/agency?", or "what can Munimji do on its own vs what do I approve?". Pass their description in businessDescription; optionally filter by area or autonomy. The AI never posts to a ledger without approval. For the full software catalog call list_features; for pricing call list_plans.
| Name | Required | Description | Default |
|---|---|---|---|
| businessDescription | No | Optional. The user describes their business and operations in their own words (industry, what they sell, how they get paid, who they pay, tax regime, pain points). It is echoed back as context — the calling assistant maps it to the returned areas + capabilities. No keyword scoring is done here; the LLM does the matching. | |
| area | No | Optional. Narrow to one business-operation area. | |
| autonomy | No | Optional. Filter Munimji capabilities by who does the work: `autonomous` (Munimji does it alone), `approval` (Munimji prepares, you approve before it posts), `assist` (co-pilot), `manual` (software feature you run yourself). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the AI never posts to ledger without approval, defines autonomy levels (autonomous, approval, assist, manual), and explains return format.
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 thorough and front-loaded with the main purpose, but slightly verbose. Every sentence adds value, but could be tightened without loss of clarity.
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 fully explains the return value: a curated capability knowledge base with areas and autonomy levels, including examples of each autonomy type. Complete for a tool with 3 optional parameters.
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%, but description adds significant meaning: explains businessDescription is echoed back, no keyword scoring; enumerates and describes area and autonomy enum values with context.
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 explains how HelloBooks and Munimji help a specific business based on a free-text description. It distinguishes from siblings by explicitly mentioning list_features and list_plans for other queries.
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?
Provides explicit when-to-use examples: 'when a user describes their business and asks 'how can HelloBooks help me?', 'what can the AI do for my shop?', etc. Also directs to alternatives for full catalog or pricing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List published articles on hellobooks.ai — head-to-head compare pages and curated flagship blog posts. Filter by country, tag or free-text query. Use this when a user asks "do you have a blog/article about X?".
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ISO country code or "global". Returns articles whose countryRelevance matches OR is "global". Omit to return everything. | |
| tag | No | Single tag to filter on (case-insensitive substring match against the article tag list). e.g. "gst", "1099", "tally". | |
| query | No | Free-text query — substring-matched against the title, excerpt and tags of each article. e.g. "QuickBooks alternative" or "audit trail". | |
| limit | No | Max articles to return (default 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations available. Description does not mention pagination, ordering, return format, or any side effects. Adequate for a read-only list tool but lacks detail.
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?
Two concise sentences: first states purpose, second gives usage context. No wasted words.
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; description does not explain return values or default behavior. Adequate for a list tool with well-described parameters.
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 has 100% description coverage; description only restates filtering capabilities without adding new meaning beyond 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?
Description clearly states 'List published articles on hellobooks.ai' with specific types (head-to-head compare pages, blog posts). Distinct from sibling analysis 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?
Provides explicit use case: 'Use this when a user asks "do you have a blog/article about X?"'. No explicit not-to-use guidance, but siblings are dissimilar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return competitor positioning entries (QuickBooks, Xero, FreshBooks, Wave, Zoho Books, Tally) with where HelloBooks wins, where the competitor wins, and pricing notes. Optional country, tier (primary / secondary), and id filters.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Only return competitors whose primary market is this country, or who are also evaluated in this market. | |
| tier | No | Filter to head-on rivals (primary) or adjacent / segment-specific overlaps (secondary). | |
| id | No | Return a single competitor by id (e.g. "quickbooks", "xero", "tally"). |
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 implies a read-only query but does not explicitly state safety, authentication, or side effects. Adequate for a simple list but lacks explicit disclosure.
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 that front-loads the main function and includes filter options. No wasted words.
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 100% schema coverage and no output schema, the description adequately explains the return content and filters. It omits pagination or limitations, but is sufficient for a straightforward 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 coverage is 100%, but the description adds significant context: it names specific competitors, clarifies id for single entry, and explains what the output contains (wins, pricing notes). This goes 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 explicitly states the tool returns competitor positioning entries, lists specific competitors (QuickBooks, Xero, etc.), and details what information is included (wins, pricing notes). This clearly distinguishes it from sibling analysis 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 explains optional filters but does not provide explicit guidance on when to use this tool versus alternatives. Usage is implied as the listing tool for competitor data among many analytical siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List HelloBooks AI credit packs — one-time pay-as-you-go top-ups (Boost 500, Power 1,500, Mega 5,000, Ultra 15,000 credits) priced in 8 regional currencies (USD, INR, CAD, GBP, AUD, AED, SGD, NZD). Credit packs stack on any plan, including Free. Use this when a user asks how to buy more AI credits or top up after exhausting a plan allowance. Filter by id (boost / power / mega / ultra) or country (ISO code).
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ISO country code. Filters prices to one country. Omit to return all 8 markets. | |
| id | No | Restrict the response to a single credit pack. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description implies a read-only operation ('List'). It explains what data is returned (packs, currencies) and notes they stack on any plan. Could mention authentication or rate limits, but basic transparency is adequate.
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?
Two sentences, front-loaded with purpose, followed by usage and filtering details. No redundant words. Each sentence adds value.
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, but description fully explains what the tool returns (list of packs with types and currencies) and notes stacking behavior. For a list tool with two optional filters, this is 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 covers both parameters with enums and descriptions (100% coverage). Description adds context: filter by id (boost/power/mega/ultra) or country (ISO code), and mentions the pack names and currencies, enhancing understanding beyond 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 HelloBooks AI credit packs, specifies the pack names (Boost, Power, Mega, Ultra) and regional currencies. It is distinct from sibling tools, all of which are analysis 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?
Explicitly tells when to use ('when a user asks how to buy more AI credits or top up after exhausting a plan allowance'). No explicit when-not-to-use or alternatives, but siblings are all different, so no confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the 13 feature categories on the marketing site (Core Accounting, Invoicing, Banking, Reports, Tax & Compliance, Inventory, Warehouse, Manufacturing, AI, Integrations, Mobile, Operations, Industry Modules) with per-category counts by status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it lists categories with counts, implying a read-only operation. However, without annotations, it could be clearer that it does not modify data. The fixed list of 13 categories and the mention of status provide adequate 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 that conveys purpose and output. It enumerates all categories, which adds length but is informative. 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?
Given no output schema and no parameters, the description provides sufficient information: it lists what categories are included and that counts per status are provided. It could clarify what 'status' means, but overall it is complete for a simple 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?
The tool has no parameters and schema coverage is 100%. The description does not need to add parameter details; it correctly focuses on output. The baseline for no 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 specifies the action (list), the resource (feature categories on the marketing site), and provides the exact list of 13 categories. It also mentions the output includes per-category counts by status, leaving no ambiguity about what the tool does.
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 the tool is used to get an overview of feature categories with counts, but it does not explicitly state when to use it versus sibling tools like list_features or when not to use it. No alternatives or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the full HelloBooks marketing feature catalog (145+ items). Filter by category, tier, status, marketedOnly, or substring query.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter to one feature category (core-accounting, invoicing-billing, etc.). | |
| tier | No | Filter by the minimum plan tier / add-on that unlocks the feature. | |
| status | No | Filter by rollout status. Defaults to all. | |
| marketedOnly | No | If true, only return features marketed on the public website. | |
| query | No | Optional substring match against label + shortDescription. | |
| limit | No | Max number of features to return. Default 200. |
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 describes a read-only operation (listing features) and mentions the catalog size and filtering, but does not disclose rate limits, authentication needs, or details about the return format.
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 states the purpose and key filtering capabilities with no wasted words, achieving excellent 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 6 optional parameters and no output schema, the description adequately covers the scope (145+ items) and filtering options. It could mention the return format or pagination behavior, but the limit parameter is documented in 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 baseline is 3. The description adds no additional meaning beyond summarizing the filter options; the schema already fully documents each parameter with descriptions and enums.
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 the full HelloBooks marketing feature catalog (145+ items) and specifies filtering options, making it distinct from sibling list tools like list_articles or list_competitors.
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?
While the description implies usage via filter parameters (category, tier, status, etc.), it does not explicitly guide when to use this tool versus sibling tools like feature_search or list_feature_categories.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List integrations (banks, payments, payroll, time tracking, shipping, accounting sync, ecommerce, CRM).
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter to one integration category. | |
| country | No | Only return integrations available in this country (or global). | |
| status | No | Filter by rollout status. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It only states 'List', implying a read-only operation, but omits details such as side effects, authentication requirements, rate limits, or pagination behavior. This is insufficient for a tool with no annotation support.
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 extraneous information. It is concise but could be slightly more descriptive 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?
For a simple listing tool with three optional parameters and no output schema, the description is marginally adequate. However, it lacks information on return format, pagination, or filtering behavior, which would be helpful for a complete understanding.
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 lists some integration categories (banks, payments, etc.) which adds slight context, but does not cover all schema options or explain the country and status parameters beyond what the schema already provides. Value added is minimal.
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 the resource 'integrations', with examples of integration categories in parentheses. This makes the purpose obvious and distinct from sibling tools like list_articles or list_features, though it could be strengthened by explicitly stating what 'integrations' encompasses.
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. There is no mention of prerequisites, context, or exclusion criteria, leaving the agent to infer usage without support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List HelloBooks pricing plans with monthly + annual prices in 8 regional currencies (USD, INR, CAD, GBP, AUD, AED, SGD, NZD). Covers three core tiers — Free, Pro, CPA/CA Partner — plus two per-entity stackable add-ons (Warehouse, Manufacturing). Returns AI credit allowance, feature bullets (AI auto-categorization, unlimited users, multi-entity, 3-way matching, API access, etc.), and the public signup URL. Filter by plan (one of free / pro / cpa) or country (ISO code). Pricing follows Doc 19 v2 (2026-05-08): Free-first + single Pro tier; the previous Business tier was merged into Pro.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ISO country code. Filters prices to one country. Omit to return all 8 markets. | |
| plan | No | Restrict the response to a single plan tier. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description provides details on output (pricing in 8 currencies, AI credit allowance, feature bullets, signup URL) and notes the pricing document version and tier structure, though rate limits or auth needs are 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 relatively long but each sentence adds value, front-loading the core purpose. Minor redundancy could be trimmed, but it remains 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?
Given no output schema, the description covers the response comprehensively: pricing, tiers, add-ons, features, signup URL, and even references the pricing document version, leaving little ambiguity.
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 context: for 'country', it explains ISO code filtering and the option to omit for all markets; for 'plan', it clarifies restricting to a single tier, enhancing the schema enums.
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 it lists HelloBooks pricing plans with specific details on currencies, tiers, add-ons, and features, distinguishing it from sibling tools like list_features or list_credit_packs.
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?
It indicates optional filters for plan and country but does not explicitly state when not to use this tool or suggest alternatives, though the context is clear given the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List statutory tax-rate slabs by jurisdiction — IN GST (5/12/18/28 + zero + exempt + composition trader/manufacturer/restaurant + compensation cess), UK VAT (20 / 5 / zero / exempt), AU GST (10 / GST-free), US sales-tax (state-administered summary, no federal rate), CA GST 5% + HST 13% ON / 15% Atlantic, SG GST 9%, NZ GST 15%, AE VAT 5%. Filter by country, taxType (GST/VAT/Sales-Tax/HST/IGST/CGST-SGST/TDS/TCS), or scheme (standard / reduced / zero / exempt / composition / cess / state-summary). Every entry carries an effective-from date and an authoritative source URL (CBIC, gov.uk, ATO, CRA, IRAS, IRD, FTA, Tax Foundation) — agents should confirm the rate against the source before quoting figures to a user. Use this when a user asks "what is the GST rate on X?", "what VAT band does Y fall into?", or "what are the composition slabs in India?". This is the public statutory reference — for an org-specific tax assignment use the authenticated books_classify_event tool.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Filter to one jurisdiction. Omit to return every supported country. | |
| taxType | No | Filter by statutory tax type (GST, VAT, Sales-Tax, HST, etc.). | |
| scheme | No | Filter by slab category — standard, reduced, zero, exempt, composition, cess. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses key behaviors: each entry has an `effective_from` date and `source` URL, advises confirming with source before quoting, and clarifies this is a public statutory reference vs. org-specific tool. This is thorough and honest.
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 lengthy but well-structured: opening with jurisdiction examples, then filtering options, then usage guidance. Every sentence adds value, though some could be slightly more concise. It's organized for quick scanning.
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 no output schema, the description explains what the response contains (effective-from date, source URL) and provides comprehensive coverage of supported countries, tax types, and schemes. It also gives guidance on confirming sources, making it complete for 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?
Schema description coverage is 100%, but the description adds significant context beyond schema enums by listing example countries and tax types, and explaining the meaning of `scheme` values (e.g., composition, cess). This helps the agent understand parameter semantics beyond just the enum values.
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 statutory tax-rate slabs by jurisdiction, provides concrete examples of rates and countries, and distinguishes from sibling tools like `lookup_tax_rate`. The verb 'list' and resource 'tax-rate slabs' is specific and informative.
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?
Explicit usage guidance: use when a user asks specific tax rate questions (e.g., 'what is the GST rate on X?'), and contrast with an alternative tool for org-specific tax assignment. This effectively helps the 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.
List HelloBooks product videos curated on the marketing site (homepage demo + feature walkthroughs) and the official @hellobooksai YouTube channel link. Each video returns title, description, category, watch URL, embed URL and thumbnail. Filter by category (demo / features / overview), featuredOnly, or free-text query. Use this when a user asks for a demo, walkthrough or video. Note: this is the curated set, not a live mirror of every channel upload — the response includes the channel URL for the full catalog.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter to one video category (demo, features, overview). | |
| featuredOnly | No | If true, only return videos flagged as featured on the marketing site. | |
| query | No | Optional substring match against video title + description. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the curated nature (not a live mirror) and explains what each video returns. There's no contradictory information. Adding details about rate limits or auth needs would improve it, but current disclosure is sufficient.
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?
Three sentences: first states purpose and returns, second lists filters, third gives usage guidance and caveat. Front-loaded, every sentence adds value, no 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?
No output schema, but the description enumerates return fields (title, description, category, watch URL, embed URL, thumbnail), covering user expectations. Filtering options and caveats are explained. No gaps for intended 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% with parameter descriptions already present. The description adds minor context (e.g., query matches title+description) but does not significantly expand beyond 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 it lists curated HelloBooks product videos with specific fields (title, description, watch URL, etc.). It mentions filtering by category, featuredOnly, and query. Sibling tools are unrelated (analysis, compliance), so this tool is distinct and its purpose is 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 explicitly says 'Use this when a user asks for a demo, walkthrough or video.' It also notes the curated nature and that the response includes the channel URL for the full catalog. While it doesn't explicitly state when not to use it, the guidance is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List local bank-rail / wallet payment methods relevant to HelloBooks invoice collection (AR), B2B supplier payments (AP), and contractor payouts (UPI, RuPay, Razorpay, IMPS, NEFT, RTGS, BACS, FPS, CHAPS, Open Banking, Interac e-Transfer, EFT, PayID, PayTo, NPP, BPAY, ACH, Same Day ACH, Fedwire, RTP, Zelle, PayNow, FAST, GIRO, NZ Direct Credit, etc.). Returns rail (instant / same-day / next-day / multi-day), use-cases, issuing authority, HelloBooks support level, and operational notes (per-transaction caps, settlement windows, retirement timelines). Filter by country, useCase, rail, or id.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Filter to one country (IN, US, CA, GB, AU, AE, SG, NZ). | |
| useCase | No | Filter by payment use-case. Defaults to HelloBooks' invoice-collection + b2b-supplier + contractor-payout scope; pass an explicit value to widen. | |
| rail | No | Filter by settlement rail (instant, same-day, next-day, multi-day). | |
| id | No | Return a single payment method by id (e.g. "in-upi", "au-payid", "us-rtp"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses what the tool returns (rail types, use-cases, issuing authority, support level, operational notes). It implies read-only behavior without stating it directly.
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?
One paragraph, front-loaded with purpose. Contains a lot of information but is still relatively concise. Could be slightly more structured (e.g., bullet points), but no unnecessary sentences.
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, but description lists what the response contains (rail, use-cases, authority, support, notes). All parameters covered, filtering explained, defaults provided. Complete 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 has 100% coverage with descriptions. The description adds context: default useCase scope, examples of IDs (e.g., 'in-upi'), and enumerates many payment methods, which adds semantics beyond 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?
Description clearly states it lists local payment methods with specific examples (UPI, RuPay, etc.) and details on what it returns (rail, use-cases, etc.). It is distinct from sibling tools which are analytical/compliance in nature.
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?
Description explicitly states filtering capabilities by country, useCase, rail, or id. It also mentions default scope for useCase and how to widen it. No explicit when-not to use, but siblings are different so context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pick a single statutory tax-rate slab — either by exact id (e.g. IN-standard-18, GB-zero-0, CA-hst-13-on) for a deterministic lookup, or by country + free-text category (e.g. "office supplies", "restaurant", "exports", "domestic fuel") for a fuzzy best-match. Returns the matched rate, the match score, and the authoritative source URL. Use this when a user asks "what slab does X fall into in India?" or "what VAT rate applies to children's car seats?". For broader exploration (all slabs in a country / all rates of one scheme), use list_tax_rates. No customer data — public statutory reference only.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Exact rate id, e.g. ``IN-standard-18`` or ``GB-zero-0``. When set, country/category are ignored. | |
| country | No | Country to search within. Required when ``id`` is not provided. | |
| category | No | Free-text query — "office supplies", "restaurant", "exports", "domestic fuel". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It explains the two lookup modes, confirms it's a deterministic vs fuzzy match, and states returns (rate, score, source URL). Lacks mention of error handling or edge cases like no match.
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?
Well-structured, front-loaded with purpose, then details modes, examples, and sibling differentiation. Every sentence adds value; no redundancy.
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 params, full schema coverage, no output schema, and no annotations, description covers both use cases, examples, and sibling tool. Lacks explicit return format details but lists returned fields. Slightly incomplete for edge cases.
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%, baseline 3. Description adds significant value: shows id format examples, explains id overrides country/category, notes category is free-text fuzzy, and provides example queries. This exceeds 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 specifies the tool picks a single tax-rate slab by exact id or fuzzy country+category match. It uses strong verbs ('pick','lookup') and distinguishes from sibling list_tax_rates for broader exploration.
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?
Explicitly tells when to use (e.g., 'what slab does X fall into in India?') and when not to (use list_tax_rates for broader exploration). Provides concrete examples and excludes customer data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.5.0analyze_balance_sheetanalyze_journal_varianceanalyze_profit_lossanalyze_qbo_journal_anomaliesanalyze_qbo_journal_cleanupanalyze_trial_balanceanalyze_xero_journal_anomaliesanalyze_xero_journal_cleanupcompare_books_to_hellobookscompliance_capabilitiescompliance_deadlinescountry_supportestimate_migration_effortfeature_searchhow_munimji_helpslist_articleslist_competitorslist_credit_packslist_feature_categorieslist_featureslist_integrationslist_planslist_tax_rateslist_videoslocal_payment_methodslookup_tax_rateScored across 26 tools
Each tool has a clearly distinct purpose, from financial statement analysis (balance sheet, P&L, trial balance) to journal analysis per platform (QBO vs Xero), compliance, features, and comparisons. No two tools overlap in function; even similar tools are differentiated by data source or specific check.
Tool names follow consistent patterns: 'analyze_' for analytical tools, 'list_' for listing tools, 'compliance_' for compliance tools, and descriptive names like 'how_munimji_helps'. No mixing of case conventions; all lowercase with underscores.
With 26 tools, the count is slightly above the ideal range but justified by the breadth of functionality—covering accounting analysis, compliance, product catalog, and competitor info. Each tool serves a distinct purpose without redundancy.
The tool surface is comprehensive for the server's purpose: financial statement analysis, journal anomaly/cleanup, migration estimation, compliance deadlines, tax rates, and full product knowledge (features, plans, integrations, videos, articles). No obvious gaps for the intended use case.
AI Accountant for Quickbooks- recording, reconcile, month-end close
Complete financial infrastructure for AI agents — payments, lending, escrow & more.
Open-source AI accounting skills verified by licensed accountants (tax, VAT, payroll).
Documents in, reconciled double-entry books out. Statements, invoices, receipts, matched and posted.
