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?
No annotations are provided, so the description fully carries the burden. It details the auto-detection of source, the three specific checks with their meanings, constraints (max 5,000 rows, 5 MB), and return fields (flags, totals, equationBalances boolean, shareable URL). There is no contradiction with any annotation since none exist.
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. It is well-structured: first states purpose, then enumerates checks, then constraints, then return values, then usage scenarios. No wasted words; the length is justified by the complexity of the 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?
The description covers all necessary aspects: input requirements, source support, checks performed, constraints, return values, and usage scenarios. Given the complexity (multiple checks, auto-detection) and the absence of an output schema, the description is complete and leaves no 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% with both parameters described. The description adds significant meaning beyond the schema: for csvText, it specifies supported sources and requirements (must include Total Assets rows); for fileName, it indicates it's for a share-page label. This fully compensates for any gaps.
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 from specific sources (QuickBooks, Xero, Zoho, Wave) and runs three named checks (accounting equation, negative assets, negative equity). It returns flags, totals, and a URL. This distinguishes it from sibling tools like analyze_profit_loss or analyze_trial_balance, which address different financial reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit usage scenarios: '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?".' It also explains the importance: a failed equation invalidates downstream analysis. However, it does not explicitly state when not to use it or provide alternatives, but 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.
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?
No annotations provided, so the description fully discloses behavior: auto-detection of source, aggregation logic, materiality thresholds (≥5% relative AND ≥$100 absolute with severity levels), input limits (5,000 rows, 5 MB), output structure (flag list, roll-up, shareable URL), and error condition for mixed sources.
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 well-structured and concise, with no fluff. It front-loads the purpose, then details algorithm, inputs, usage, and output in logical order.
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 (multiple inputs, thresholds, output), the description is comprehensive. It covers behavior, constraints, usage, and error conditions without requiring 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 description coverage is 100%; the description adds context (e.g., periodACsv is earlier, labels appear in flag messages) but does not significantly expand beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'compare', resource 'journal-entry data', and outcome 'flag accounts whose movement deviates materially between periods'. It distinguishes from sibling tools like analyze_qbo_journal_anomalies by focusing on period-over-period comparison rather than intra-period anomalies.
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 cues are provided: 'when a user pastes two periods and asks "what changed?", "show me variances", "what jumped period-over-period"'. It also indicates constraints (max rows, same source) but does not explicitly name alternative tools for different scenarios.
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?
The description fully discloses the tool's behavior: it runs three checks, returns flags and summary, and creates a shareable URL. Input constraints (max 5000 rows, 5 MB) are provided. However, it does not discuss error handling or behavior when input is malformed, which would be useful.
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, front-loaded with purpose, then checks, then usage guidance. It is slightly long but every sentence adds value. Could be more terse, but clarity is not sacrificed.
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 return values (flags, summary fields, URL). It also covers input requirements and sibling differentiation, making it complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds significant value: for csvText it details the expected format, source auto-detection, and what the statement should include; for fileName it explains its optional role in the 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 clearly states the tool's purpose: taking a P&L CSV from specific sources and running three checks. It distinguishes from sibling tools by noting it is single-period only, explicitly contrasting with analyze_journal_variance.
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 use cases ('when a user pastes a P&L and asks...') and explicitly states when not to use it (period-over-period comparison should use analyze_journal_variance). This gives clear guidance on proper invocation.
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?
No annotations provided, so the description bears full burden. It discloses input format, row and size limits, output structure with severity levels, and that it only detects round numbers. This is comprehensive and sets proper expectations.
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 with the main action first, then details, usage, and limitations. It is slightly verbose with explanatory notes about rounding numbers, but each sentence contributes useful context for an AI agent.
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 output format and severity thresholds. It covers input constraints, usage context, and limitations (Tier-0, only round numbers). For a tool with two parameters and no output schema, this is highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, yet the description adds clarity: defines csvText as raw CSV from a specific QBO export, and fileName as a label. It also mentions max rows and size not in schema. This adds meaningful value 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 scans a QBO Journal Entries CSV for round-number anomalies, specifying the type of anomaly and the context. It distinguishes from siblings like analyze_xero_journal_anomalies by explicitly mentioning QBO, and from the paid product by calling it a Tier-0 subset.
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 usage examples ('when a user pastes QBO data and asks...'). It does not explicitly list alternatives among sibling tools, but the QBO-specific focus and description of what it detects imply when to use it. Slight room for improvement in naming when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 constraints, output structure (flags, summary, diagnostics, shareable URL with TTL), and fixableInHellobooks boolean. It is transparent about being a read-only analysis tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with core purpose and then provides structured details (issues, input format, limits, output, usage triggers). Each sentence adds value, though it is slightly long; still well-organized.
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?
Although there is no output schema, the description thoroughly explains the output: structured flag list with severity, roll-up summary, parse diagnostics, and shareable URL with TTL. It also covers input limits and usage triggers, making it complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds value by explaining the csvText parameter's export path and pasting instructions, and fileName's optional use. This goes beyond the schema, so a 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans a QBO Journal Entries CSV for three specific cleanup issues (unbalanced, duplicate, schema problems). It also mentions the fixableInHellobooks flag, distinguishing it from sibling tools like analyze_qbo_journal_anomalies.
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 or asks 'check my books', 'find issues in my QBO journal', etc. Also specifies input format, export path, and limits (max 5,000 rows, 5 MB). No exclusion clauses but clear context.
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?
Discloses auto-detection of source, three checks, output types (flagged accounts, roll-up, diagnostics, shareable URL), and constraints (max rows/size). Without annotations, this is thorough, though error handling could be 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?
Well-structured with numbered checks and clear output list. Slightly verbose but each sentence adds value; could be slightly tighter.
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?
Describes return values (flags, roll-up, diagnostics, URL) despite no output schema. Covers input and behavior adequately. Missing error handling details.
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 explaining compatible sources, auto-detection logic, and the optional fileName. This provides meaningful context 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 defines the tool's purpose: analyzing a Trial Balance CSV from multiple sources by running three specific checks. It distinguishes from sibling tools that handle other financial statements or journal anomalies.
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 lists use cases (e.g., 'does my TB balance?') and emphasizes the foundational importance of the TB. While no explicit 'when not to use' is stated, the sibling context makes it clear.
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?
Discloses input limits (max 5,000 rows, 5 MB), output structure (flagged lines with severity and URL), and that it is not history-aware (advanced checks in paid product). With no annotations, description fully shoulders transparency burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Packed with essential information in a structured flow: purpose, input, constraints, output, usage scenarios, and differentiation. No wasted 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?
Comprehensive coverage given no output schema or annotations: explains input format, output details, constraints, usage context, and limitations (only round numbers, not history-aware). Completeness is high.
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 provides full descriptions for both parameters (100% coverage). Description adds constraints (max rows/size) not in schema, but no other substantive 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?
Clearly states it scans Xero Manual Journals CSV for round-number anomalies, specifying input source, what anomalies it finds, and output (flagged lines with severity and shareable URL). Distinguishes from sibling tools by mentioning QBO variant and paid product for advanced 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?
Explicitly says 'Use this when a user pastes Xero data and asks any anomalies?, look for round numbers, or anything suspicious.' Contrasts with paid product for deep analysis, providing clear when-to-use and when-not-to-use guidance.
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?
With no annotations, the description fully covers behavioral traits: Xero idioms handled, row/size limits, output structure (flags, summary, diagnostics, shareable URL). 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?
Well-structured and front-loaded with core function. Slightly lengthy but every sentence adds value. Efficient overall.
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?
Comprehensive coverage of input, processing, constraints, and output despite no output schema. No obvious gaps given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds minor context (Xero idioms, limits) but does not significantly enhance understanding beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans Xero Manual Journals CSV for specific issues (unbalanced, duplicates, schema problems). It distinguishes from siblings by being Xero-specific and cleanup-focused.
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 data, asks to check books). Provides input format guidance. Lacks explicit when-not-to-use, but context is clear with sibling tools.
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 the detection sets (imbalance, duplicates, round-number, schema) and output structure, but does not state whether the tool is read-only, any side effects, or authentication requirements. Adequate but incomplete.
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 long and contains multiple details. While front-loaded with core action, it includes redundant phrasing and could be trimmed. Every sentence adds value, but overall verbosity reduces 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?
The description comprehensively covers input format, detection sets, output structure (per-category counts mapped to phases, exclusive-advantage bullets), and use cases. However, it does not specify the exact output format (e.g., JSON), which is a minor gap given no 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 description coverage is 100%, so baseline is 3. The description adds context about auto-detection and optional filename, but does not significantly enhance understanding of parameters beyond the schema. Score 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 (take, run, return) and resource (journal-entry CSV), and specifies the tool compares QBO/Xero data to HelloBooks, distinguishing it from sibling analysis tools. However, the description is somewhat verbose, reducing clarity slightly.
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: 'when a user is evaluating HelloBooks vs their current QBO/Xero, asks "should I migrate?", or pastes data while comparing accounting software.' This is clear and directive, leaving no ambiguity about when to invoke the tool.
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 full burden. It clarifies that the tool returns frameworks with version and certification info, indicating a read operation. It does not disclose auth needs or rate limits, but for a simple query tool, the description is adequately transparent.
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 communicates the tool's purpose and key details. There is no redundant information, and critical information (verb, resource, examples, extra info) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description fully explains what the tool returns (frameworks with version and certification info) and when to use it (by country). It is complete for an agent to understand and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for the 'country' parameter. The description does not add new semantic details about the parameter beyond stating it's for a country and listing example frameworks, which are return values. Thus, it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Return' and clearly identifies the resource 'supported compliance frameworks' with concrete examples (BAS, STP, GST, etc.). It distinguishes itself from siblings like 'compliance_deadlines' by focusing on frameworks rather than 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 explicitly says 'for a country', providing clear context for when to use the tool. It does not list alternatives or exclusions, but the sibling 'compliance_deadlines' is implicitly differentiated. The guidance is sufficient for an agent to select the correct tool.
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?
With no annotations, the description carries full burden and discloses key traits: dates rotate annually, each response includes a disclaimer with a source URL for confirmation. It also specifies coverage by country and form.
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: a few sentences covering purpose, examples, optional filters, and a note on annual rotation. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool returns (deadlines with disclaimer and source URL), covers the scope of countries and forms, and mentions the annual rotation. No output schema is needed; the description is complete for decision-making.
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 context: country parameter notes ISO code and current coverage, frequency explains cadence, and form specifies substring match and case-insensitivity, going beyond the schema's basic 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 'when statutory returns and payroll filings are due, per country', listing specific forms and countries. It distinguishes from sibling tools like compliance_capabilities and list_tax_rates, which cover different aspects.
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 indicates optional filters (country, frequency, form) and provides examples of usage. However, it does not explicitly state when to use this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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?
With no annotations, description carries full burden. It does not disclose behavior when country is omitted (e.g., returns full matrix) or any other traits like rate limits or output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with purpose, 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?
For a simple tool with one optional parameter and no output schema, the description is mostly complete. Could slightly improve by mentioning the default behavior when country is omitted.
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%; the schema already explains the parameter (ISO code and omission behavior). The tool description adds no additional semantic value.
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 returns features per supported country and lists the supported countries. Distinct from sibling tools which are analytical or compliance-related.
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?
Implies use when needing features per country, but no explicit guidance on when to use vs alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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?
With no annotations, the description fully discloses heuristic nature, refinement after signup, and file size limits (50k rows/20MB). It clarifies this is a sizing-only tool (no detection) and implies it is non-destructive.
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 fairly long but well-structured: front-loaded with core function and outputs, then details file limits, usage context, and CTA. Most sentences add value, though the CTA could be considered extra.
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 effectively enumerates return fields. It covers input format, source detection, size limits, and typical use cases. Missing details on error handling, but sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (csvText described). The description adds meaning for csvText (source auto-detection, expected format) but not for fileName. Overall, it compensates partially for the missing schema detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a concrete action ('estimate migration effort') on a clear input (QBO/Xero journal CSV) and lists specific outputs (row counts, cost estimate). It differentiates from sibling analytical tools by mentioning larger file acceptance and no detection.
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 (user weighing migration cost, asking cost/time questions) and provides a CTA. It does not explicitly name alternatives but contrasts with 'other analytical tools,' making usage context clear for an agent.
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?
With no annotations provided, the description does not disclose behavioral details beyond the search mechanism. It mentions 'surface the matching entry near the top' suggesting relevance ordering, but does not address pagination, result format, error handling, or rate limits. The description adds some context but not comprehensive behavioral 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 paragraph that packs in many examples and content types. While informative, it could be more concise by grouping examples or using bullet points. It front-loads the purpose well but loses some conciseness due to excessive examples.
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 relative simplicity (two parameters, no output schema), the description covers the input semantics and search scope adequately. It explains what content is searched and provides query patterns. With no output schema, it could hint at return structure, but the examples suffice for an agent to understand expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides min/max lengths and range for limit, but the description enriches this by listing example queries and clarifying the scope of searchable content. It goes beyond the schema's parameter descriptions, which are somewhat generic, by showing realistic usage patterns.
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 performs free-text search across a specific catalog of marketing features, plans, integrations, etc. It lists diverse example queries like 'vs Xero' and 'GSTR-3B due', making the purpose unmistakable and distinguishing it from more specific sibling tools like list_features or list_integrations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for open-ended queries across many content types, contrasting with sibling tools that are lists or analyses. It provides concrete query examples that guide the user, but lacks explicit 'use when' or 'use instead of' statements. The examples implicitly show when to use this tool over others (e.g., searching for competitive information vs list_competitors).
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?
Discloses key behaviors: the AI never posts to ledger without approval, businessDescription is echoed as context, no keyword scoring is performed, and output includes autonomy levels. Since no annotations are provided, the description carries full burden and does so thoroughly.
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 long but well-structured: purpose, output explanation, example queries, parameter guidance, cross-references. It is front-loaded with the most important information. Slightly repetitive with schema details but earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description thoroughly explains the output structure (areas, autonomy levels, capabilities). It covers the tool's function, parameters, and usage context comprehensively.
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 rich parameter descriptions already. The tool description adds context on usage but does not significantly extend meaning beyond what is in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: explaining how HelloBooks and Munimji help a business given a free-text description of operations. It distinguishes from sibling tools like list_features and feature_search by providing cross-references.
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 provides example queries that trigger use of this tool (e.g., 'how can HelloBooks help me?'), explains when to use it vs alternatives, and suggests calling list_features for full catalog or list_plans for 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 are provided, so the description carries the full burden. It correctly implies a read-only operation and describes filtering capabilities, but does not disclose details like pagination, rate limits, or what happens with omitted filters. The behavior is predictable but minimally documented.
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 with front-loaded purpose. Every sentence adds value: first states what the tool does, second gives a direct usage example. 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?
Without an output schema, the description does not explain the return format or structure. However, the tool is a simple list operation with self-explanatory parameters and no nested objects. The description is sufficient for an AI agent to invoke it correctly, though a brief note on output format would improve 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 description coverage is 100%, so baseline is 3. The description 'Filter by country, tag or free-text query' adds marginal value beyond the schema, which already explains matching behavior. No additional semantic guidance is provided for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and resource 'published articles on hellobooks.ai', specifying subtypes like 'head-to-head compare pages and curated flagship blog posts'. This distinguishes it from sibling list tools (e.g., list_competitors) which focus on different resources.
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 an explicit use case: 'Use this when a user asks "do you have a blog/article about X?"'. However, it does not mention when not to use it or provide alternatives among siblings, though the context makes alternatives obvious.
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?
With no annotations, the description explains the output (winners, pricing) and optional filters, but does not disclose data freshness, source, or any restrictions. Adequate for a read-only list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and output, with no unnecessary 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?
The description explains return values sufficiently given no output schema, covering the essential aspects. It could specify the structure of each entry, but is largely 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 coverage is 100% and the description merely repeats the optional filters without adding new semantic context or examples. Baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns competitor positioning entries, listing specific competitors and describing the content (wins, pricing notes). It distinguishes from sibling tools like compare_books_to_hellobooks which perform different comparisons.
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 when competitor positioning info is needed, but does not provide explicit guidance on when to use it versus alternatives, such as compare_books_to_hellobooks or feature_search.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns exactly 13 categories (listed) and includes per-category counts by status, which is adequate transparency for a read-only listing tool. 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 a single sentence that efficiently conveys all necessary information with 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 zero parameters, no output schema, and no annotations, the description completely covers the tool's behavior. It specifies the exact output (13 categories with counts by status), which is sufficient for an agent to understand 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?
The tool has no parameters, so the baseline is 4. The description adds meaning by specifying what the output contains (categories and counts), which goes beyond the empty 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 the 13 specific feature categories on the marketing site and provides per-category counts by status. The verb 'list' matches the resource 'feature categories', and the explicit enumeration of categories distinguishes it from siblings like list_features or list_integrations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a user needs an overview of feature categories with counts, but it does not explicitly state when to use this tool versus alternatives (e.g., list_features for detailed feature info) or provide any exclusions.
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?
No annotations provided, so the description shoulders the full burden. It only states 'List integrations' with categories, omitting behavioral traits like read-only nature, pagination, rate limits, or auth requirements. This is insufficient for an agent to understand the tool side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it lacks structural elements like a summary or usage notes. Its brevity comes at the cost of missing critical information, making it only marginally better than a tautology.
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?
Without an output schema, the description should clarify return format and behavior (e.g., whether it returns all integrations or just names). The current description only lists categories, leaving the agent guessing about the response structure and default behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a clear description and enum values. The description adds minimal extra value beyond listing example categories that loosely map to the category enum. Baseline 3 is appropriate as the schema already does the heavy lifting.
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 integrations, listing example categories. This is a specific verb+resource combination, distinguishing it from analysis and compliance siblings. However, it does not explicitly state what the list contains (e.g., names, IDs), which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other list_* siblings or alternatives. The description does not mention any conditions, prerequisites, or limitations, leaving the agent without context for selection.
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 bears full burden. It specifies that each entry carries an effective-from date and source URL, and warns agents to confirm against source. It implies read-only behavior but does not explicitly state auth requirements or rate limits.
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 detailed but well-structured, front-loading the purpose. It could be slightly more concise, but every sentence provides relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return fields (effective-from, source) and covers multi-country complexity. Complete for a list 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 covers 100% of parameters with descriptions and enums. The description adds value by providing examples of how to use filters (e.g., 'Filter by country, taxType, or scheme') and specifying the filtering capabilities.
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 statutory tax-rate slabs by jurisdiction, provides specific examples for multiple countries, and distinguishes from sibling tools like lookup_tax_rate and books_classify_event.
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 (e.g., 'what is the GST rate on X?') and when not to ('for an org-specific tax assignment use the authenticated books_classify_event 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 the full burden. It discloses the curated behavior and includes the channel URL for full catalog. However, lacks details on pagination, ordering, or response limits.
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?
Concise, front-loaded with purpose, and every sentence adds value. 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?
For a list tool with 3 optional params and no output schema, the description covers the return fields and channel URL. Minor omission: default behavior when no filters are applied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining 'free-text query' and grouping filters, providing context 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 uses specific verbs ('List') and resources ('HelloBooks product videos curated on the marketing site'). It clearly distinguishes the curated nature from sibling tools and states the return fields.
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: 'Use this when a user asks for a demo, walkthrough or video.' It also notes it's a curated set, implying not for searching all channel uploads. However, no explicit when-not or alternative tool mention.
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 are provided, so the description must convey behavioral traits alone. It details the output fields (rail, use‑cases, issuing authority, support level, operational notes) and implies a read‑only listing. A minor gap is lack of explicit statement that it is safe/non‑destructive, but the content strongly suggests that.
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 detailed but not wasteful; it front‑loads the purpose and example methods. One minor point: it could be slightly more concise by grouping examples, but the informativeness justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 optional parameters, no output schema, and no annotations, the description fairly completely explains what the tool does, what it returns, and how to filter. Missing are pagination or limit details, but these are often not critical for a list of payment methods. Overall it provides enough context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the default use‑case scope and listing example payment methods, which provides richer context beyond the schema descriptions. For instance, it clarifies that the default filter is helloBooks' core use cases.
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 resource ('local bank-rail / wallet payment methods'), the context ('HelloBooks invoice collection, B2B supplier payments, contractor payouts'), and gives concrete examples (UPI, RuPay, NEFT, etc.). It clearly distinguishes from sibling tools like list_tax_rates or list_credit_packs, which serve different domains.
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 states filtering options by country, useCase, rail, or id and notes the default scope. While it doesn't explicitly contrast with siblings, the context makes it clear this is the go‑to tool for payment method lookup. A small improvement would be adding a sentence like 'Use this when you need to find available payment rails for a country or use case.'
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns matched rate, match score, and source URL, and states it is a public statutory reference with no customer data. It does not detail match algorithm or failure modes, but is sufficient for a read-only lookup.
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, well-structured, and front-loaded with action and scope. Every sentence adds value, includes examples, and provides guidance without 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 no output schema and simple lookup nature, the description covers purpose, parameter behavior, output elements (rate, score, source), and distinguishes from sibling tool. It is complete and leaves no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds significant meaning beyond the schema by explaining the exact vs fuzzy mode, id override behavior, providing concrete examples of id formats and category queries, and tying parameters to use cases.
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 does a single lookup of a statutory tax rate slab, with two modes (exact by id or fuzzy by country+category). It distinguishes from the sibling tool list_tax_rates for broader exploration, using specific verbs like 'pick' and 'lookup'.
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 when to use this tool (specific queries like 'what slab does X fall into?') and when not to ('For broader exploration... use list_tax_rates instead'). It includes example queries and clarifies that no customer data is involved.
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. Dates show when Glama detected each change.
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_rateEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Meru-Fin-Tech/HelloBooks-MCP-Public'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
