HelloBooks AI Agents

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

With no annotations, the description fully discloses behavior: input format (CSV), sources, row/size limits, three check definitions, output fields (flags, totals, URL), and the critical implication that a failed equation invalidates downstream ratios.

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

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

The description is well-structured with a clear list of checks, input specs, output description, and use cases. It is slightly long but each sentence adds value; minor redundancy in the importance statement.

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

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

Given the tool's complexity (3 checks, multiple sources), the description covers inputs, constraints, outputs, and use cases adequately. Without an output schema, it still explains return values (flags, totals, URL). It could detail flag severity, but is sufficient.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds context beyond schema: for csvText it specifies required rows (Total Assets, etc.) and source auto-detection; for fileName it notes optional label for share page.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool takes a Balance Sheet CSV and runs three specific checks (equation, negative asset, negative equity), with source auto-detection. It distinguishes from sibling tools by focusing on balance sheet-specific checks and notes it's the most important check for any BS.

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

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

The description explicitly says 'Use this when a user pastes a Balance Sheet and asks...' and gives three example questions. It could mention alternatives like analyze_profit_loss for income statements, but the use cases are clear.

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

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

Describes aggregation, threshold logic (≥5% relative and ≥$100 absolute with severity levels), output format (flag list, roll-up, shareable URL), and error condition (mixing sources). Without annotations, it covers key behaviors well, though no mention of read-only/destructive nature.

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

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

Front-loaded with purpose, then detailed constraints and logic. Every sentence contributes value; slight redundancy in source-matching requirement but overall efficient.

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

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

Given complexity (two CSVs, auto-detection, threshold logic, no output schema), description covers input requirements, processing, output format, and error conditions thoroughly. No gaps evident.

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

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

Schema coverage is 100%, but description adds crucial semantics: clarifies earlier vs later period, auto-detection, max sizes, optional labels for human readability. Adds value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool compares two periods of journal-entry data and flags accounts with material variance. Differentiates from sibling tools like anomaly detection or cleanup tools by focusing on period-over-period variance for both QBO and Xero.

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

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

Provides explicit use cases (e.g., 'what changed?', 'show me variances') and constraints (max rows/size, source matching). Lacks explicit 'do not use when' statements but gives strong positive guidance.

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

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

Since no annotations are provided, the description carries the full burden. It details the three checks, the output format (flags with severity, summary with fields, shareable URL), and input limits (max 5000 rows, 5 MB). It does not explicitly state that the tool is read-only or non-destructive, but this is implied by the nature of analyzing CSV text.

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

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

The description is well-structured and front-loaded with the tool's purpose and checks. It is relatively long but every sentence adds value, including usage examples and alternative tool reference. Could be slightly more concise but remains clear.

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

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

Given the complexity (three checks, multiple sources, auto-detection), the description covers input format, output fields, limits, and alternative usage. No output schema exists, so the description adequately explains return values (flags, summary, URL) and usage context.

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

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

With schema description coverage at 100%, baseline is 3. The description adds meaning beyond the schema for csvText by specifying supported sources (QuickBooks, Xero, etc.) and required structure (section headers, subtotals, net income row). For fileName, it repeats the schema description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool takes a P&L CSV and runs three specific checks (subtotal mismatch, negative expense, margin red flag). It distinguishes itself from the sibling tool analyze_journal_variance by noting that tool is for period-over-period comparison, while this is single-period.

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

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

The description explicitly provides usage scenarios: 'Use this when a user pastes a P&L and asks...' and gives example user queries. It also tells when not to use it, directing to analyze_journal_variance for period-over-period comparison.

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

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

With no annotations, the description fully discloses behavior: input format (raw CSV text from QBO Reports → Accountant → Journal), limits (max 5,000 rows, 5 MB), output (flagged lines with severity and a shareable URL), and what the tool does not do (paid product features). No contradictions.

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

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

The description is well-structured and front-loaded with the core purpose. Every sentence adds value—input details, use cases, limitations, and relation to paid features. No redundant or wasted words.

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

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

Given the complexity of anomaly detection and absence of an output schema, the description is remarkably complete. It covers input, output, use cases, limits, severity levels, and ties to the product roadmap, leaving no critical gaps for an AI agent.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds context beyond the schema by explaining the expected CSV format and the purpose of the optional fileName as a label. This extra information raises the score slightly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool scans a QBO Journal Entries CSV for anomalies, specifically round-number lines. It distinguishes itself from sibling tools like analyze_xero_journal_anomalies and analyze_qbo_journal_cleanup by specifying the exact input source and type of anomaly.

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

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

Explicitly mentions when to use: when a user pastes QBO data and asks 'any anomalies?', 'look for round numbers', or 'anything suspicious'. It also clarifies this is a Tier-0 subset and that the paid product has additional capabilities, providing clear context and alternatives.

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

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

No annotations provided, so description carries full burden. It discloses input limits, output structure, and shareable URL with TTL. However, it does not explicitly state the tool is read-only or has no side effects.

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

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

Description is detailed and informative but somewhat long. Every sentence adds value, though it could be slightly more compact without losing clarity.

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

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

Fully covers what the tool does, when to use it, input requirements, output breakdown (flags, summary, diagnostics, shareable URL), and limits (5000 rows, 5MB). No output schema, so description compensates well.

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

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

Both parameters are described in schema with 100% coverage. Description adds context: how to obtain the CSV (QBO export path), max size constraints, and the purpose of fileName as a label.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies the exact actions: scanning QBO journal CSV for unbalanced, duplicate, and schema issues. It clearly distinguishes from siblings by naming QBO cleanup and listing specific categories.

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

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

Explicitly states when to use: when user pastes QBO journal data and asks specific queries like 'check my books' or 'find issues'. Implicitly excludes Xero-related tools.

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

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

With no annotations, the description fully discloses behavioral traits: auto-detection of CSV source from headers, max rows/ size limits, the three checks performed, and the returned data (flagged accounts, severity, roll-up, diagnostics, shareable URL). It also warns about downstream report invalidity if the TB is unbalanced.

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

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

The description is relatively long but well-structured: it starts with the tool's purpose, lists the checks, specifies input constraints, and describes output. Every sentence provides essential information; however, it could be slightly more concise without losing clarity.

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

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

Given no output schema, the description adequately explains the return values (flagged accounts with severity, roll-up, diagnostics, shareable URL) and input limits. It lacks exact output structure details, but the summary is sufficient for an agent to understand what to expect.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds significant value beyond the schema by explaining how csvText is used (raw CSV from specific sources), the auto-detection logic, the three checks, and that fileName is optional for a share-page label.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('analyze') and resource ('Trial Balance CSV') and clearly distinguishes the tool from sibling tools by detailing the three specific checks (unbalanced, wrong sign, round balance) and listing supported accounting software. No sibling tool covers trial balance validation.

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

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

The description explicitly states when to use the tool: 'when a user pastes a Trial Balance and asks...' and provides example queries. It does not explicitly mention when not to use it or suggest alternative tools for other financial statements, but the context is clear enough for correct selection.

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

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

With no annotations, the description fully discloses behavioral traits: input is raw CSV, max 5,000 rows/5 MB, returns severity-labeled flagged lines and a shareable URL. It also clarifies the scope (only round-number anomalies) and product tier.

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

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

The description is thorough and front-loaded with the main purpose, but it includes some longer sentences that could be slightly more concise. Overall, it is well-structured.

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

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

The description covers input format, size limits, output structure, and product context, making it complete for an anomaly-detection tool without an output schema.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds minimal semantic value beyond the schema: it restates the CSV source but does not elaborate on the fileName parameter's use.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool scans Xero Manual Journals CSV for round-number anomalies, specifying the threshold and output format. It distinguishes from sibling tools by mentioning the QBO variant and the split between unauthenticated and authenticated checks.

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

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

The description provides explicit context for when to use the tool (e.g., user asks 'any anomalies?') and notes that advanced history-aware checks are in the paid product, but it does not explicitly list when not to use it.

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

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

No annotations provided, so description fully covers behavior: Xero-specific idioms (signed Amount, Debit/Credit, Reference/Narration grouping), limits (5,000 rows, 5 MB), output structure (flags, summary, diagnostics, URL), and funnel CTA.

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

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

Every sentence earns its place: purpose, input source, idioms, constraints, output, use case, CTA. Well organized and front-loaded with main action.

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

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

Covers all necessary aspects: input format, behavioral details, output summary, and usage case. No output schema, but description explains return values sufficiently.

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

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

Schema coverage is 100%, but description adds crucial context: input is raw CSV from specific Xero export, fileName is optional label. Explains what the CSV contains and how to obtain it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States exactly what the tool does: scan Xero 'Manual Journals' CSV export for cleanup issues (unbalanced, duplicate, schema). Distinct from sibling QBO or anomaly tools by specifying Xero and cleanup focus.

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

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

Explicitly says when to use (user pastes Xero manual-journal data, asks check/find issues). Gives exact export path. Does not explicitly exclude alternatives, but context is clear enough.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool auto-detects the source, runs multiple detection sets, and returns a structured comparison with per-category counts and advantage bullets. It does not mention side effects, but the tool appears to be a read-only analysis. Minor gap: no explicit statement of non-destructiveness or error handling for invalid input.

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

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

The description is well-structured with three sentences: core function, use case, and output/appropriateness. It is front-loaded with the action. While somewhat long, each sentence adds distinct value, making it efficient.

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

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

Despite no output schema, the description thoroughly explains the output structure (per-category counts, phases, exclusive-advantage bullets, share URL). It covers input, processing, output, and use case, providing complete context for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100% with clear parameter descriptions for csvText and fileName. The tool description adds value by explaining the purpose of the CSV, auto-detection, and the mapping of results to HelloBooks phases, which goes beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: taking a QBO or Xero journal-entry CSV, running a detection set (imbalance, duplicates, etc.), and returning a structured side-by-side comparison. It specifies the output includes per-category counts mapped to HelloBooks phases and exclusive-advantage bullets, distinguishing it from sibling analysis tools.

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

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

The description explicitly says when to use: when a user is evaluating HelloBooks vs QBO/Xero, asks about migration, or pastes data for comparison. It notes the output is suitable for the host LLM to narrate as a positioning argument. However, it lacks explicit when-not-to-use guidance, though the context is clear.

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

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

No annotations are provided, so the description carries the full burden. The verb 'Return' suggests a read-only operation, but it does not explicitly declare the tool as safe or idempotent. It also omits details like authorization needs or data freshness.

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

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

The description is a single, well-structured sentence that front-loads the verb 'Return' and concisely conveys the tool's purpose and output details without any fluff.

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

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

Given the tool's simplicity (one parameter, no output schema), the description covers the core purpose and output nature. However, it could be more complete by specifying the exact structure of the returned data (e.g., list of frameworks with fields like name, version, certification).

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

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

Schema coverage is 100% for the single required parameter 'country' (ISO code with enum). The description adds value by listing example frameworks (BAS, STP, etc.) that are associated with each country, providing context beyond the enum values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns supported compliance frameworks for a given country, listing examples (BAS, STP, etc.) and mentions version/certification info. This differentiates it from siblings like compliance_deadlines or country_support.

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

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

The description implies when to use this tool (to retrieve country-specific compliance frameworks) but does not explicitly state when not to use it or mention alternatives. It is clear within the context of siblings.

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

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

Without annotations, the description carries full burden. It discloses that dates rotate annually and that responses include a disclaimer with source URLs for authority confirmation. It also lists covered forms, offering good transparency. Missing details on return format or error handling prevent a 5.

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

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

The description is concise (3 sentences) and front-loaded with the main purpose. Every sentence adds useful information without waste.

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

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

Given the tool has 3 optional parameters and no output schema, the description adequately explains what the tool returns (deadlines with source URLs) and the filter options. It covers the key aspects, though timezone or date format details would add completeness.

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

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

Schema coverage is 100%, but the description adds value by providing concrete examples (e.g., 'GSTR-3B', 'BAS') and explaining the purpose of each filter. This goes beyond the schema's generic descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'when statutory returns and payroll filings are due, per country.' It lists specific countries and forms, and distinguishes from siblings like list_tax_rates or compliance_capabilities by focusing on deadlines.

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

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

The description provides usage context by listing optional filters (country, frequency, form) and noting that dates rotate annually. However, it does not explicitly state when to avoid this tool or mention alternatives, which prevents a higher score.

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

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

No annotations provided, so the description carries full burden. It only says 'Return features', implying a read operation, but does not disclose any behavioral traits such as idempotency, rate limits, or return format. For a simple read tool, this minimal transparency is a gap.

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

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

The description is a single sentence with no wasted words. It front-loads the key information: what the tool does and the supported countries. Ideal conciseness for a simple lookup tool.

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

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

Given the tool's simplicity (1 optional param, no output schema), the description is adequate but lacks details about the return format or possible errors. The mention of 'full matrix' in the schema is not in the description. More completeness would be beneficial, but the tool is straightforward.

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

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

Schema description coverage is 100% (parameter has a description: 'Single ISO country code. Omit for the full matrix.'). The description adds the list of supported countries, which is marginally helpful but does not add new semantics beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Return', the resource 'features available per supported country', and lists the specific country codes. It distinguishes this tool from siblings like 'compliance_capabilities' which likely return compliance-related data rather than general features.

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

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

No guidance on when to use this tool versus alternatives (e.g., compliance_capabilities). The description does not specify when not to use it or mention any preconditions.

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

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

No annotations provided, so description carries full burden. It discloses heuristic-based behavior, refinement upon signup, and larger file limits. However, it does not explicitly state that it is read-only or non-destructive, which would be helpful given the absence of annotations.

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

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

The description is reasonably concise with three substantive sentences. It is front-loaded with the main purpose and adds useful details. The final sentence about the funnel CTA is slightly tangential but still relevant for context.

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

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

Given the tool has 2 parameters and no output schema, the description thoroughly covers the output structure (row counts, account count, complexity, hours, price quote) and explains the heuristic approach. It is complete for a sizing tool, though it could mention error handling for invalid CSVs.

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

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

Schema has 2 parameters (csvText required, fileName optional) with 50% description coverage (only csvText described). The description adds meaning by explaining source auto-detection and file size constraints, but does not describe the fileName parameter, leaving it under-specified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the tool takes a QBO or Xero journal-entry CSV and returns a structured migration-effort estimate with specific metrics like row counts, unique accounts, and complexity classification. It is distinct from sibling analysis tools.

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

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

The description explicitly states when to use: when a user is weighing migration cost, asks about time or cost, or asks if it's worth migrating. It also notes larger file acceptance. However, it does not explicitly list when not to use or name alternatives.

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

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

No annotations are provided, so the description carries full burden. It discloses that matching entries appear 'near the top', implying ranking, but does not specify search algorithm (e.g., fuzzy vs exact), result format, or whether it requires authentication. Adequate but not detailed.

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

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

The description is a single, well-structured paragraph that front-loads the scope of search and immediately follows with concrete examples. Every sentence is informative with no redundancy.

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

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

For a search tool with no output schema, the description adequately explains what is searched and gives sample queries. It could mention that results are ordered by relevance or how the limit parameter affects pagination, but overall it provides sufficient context.

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

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

Schema coverage is 100%, both parameters already have descriptions. The description adds value by providing realistic example queries for the 'query' parameter, helping agents understand the range of inputs. No extra detail for 'limit' beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is a free-text search across many specific catalogs (marketing features, plans, integrations, etc.) and provides multiple example queries, making its purpose distinct from sibling list or analysis tools.

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

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

The description implies this tool should be used for broad, semantic queries (e.g., 'vs Xero', 'GSTR-3B due') rather than exact list lookups. It does not explicitly exclude cases, but the context is clear enough for an agent to decide.

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

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

With no annotations, the description carries full burden. It explains that exceeding the threshold forces an upgrade, and that certain financial metrics are not used. It is transparent about the logic, though it does not describe error handling or exact output 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 relatively long but each sentence adds necessary detail. It is front-loaded with the main purpose and well-structured, though it could be slightly more concise.

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

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

Given no output schema and no annotations, the description adequately covers the three usage modes and the business logic. It does not describe response structure or errors, but for a simple threshold tool, it is fairly 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%, baseline 3. The description adds meaning by noting that annualInvoiceRevenue must be in home currency (not USD-equivalent) and that it is only used with country. It also hints at the output (freeEligible verdict).

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 HelloBooks Free-plan annual-invoice-turnover thresholds for 8 countries. It uses specific verbs ('Return') and resources ('thresholds'), and the sibling tools are all analysis tools, making this distinct.

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 lists three calling patterns: no args for full table, country alone for one threshold, and country with annualInvoiceRevenue for a freeEligible verdict. It also clarifies that bank-feed total and cash receipts are not used, providing clear when-to-use guidance, though it doesn't mention 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.

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

No annotations provided, so description carries full burden. It discloses that the AI never posts to ledger without approval, defines autonomy levels (autonomous, approval, assist, manual), and explains return format.

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

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

The description is thorough and front-loaded with the main purpose, but slightly verbose. Every sentence adds value, but could be tightened without loss of clarity.

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

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

Given no output schema, the description fully explains the return value: a curated capability knowledge base with areas and autonomy levels, including examples of each autonomy type. Complete for a tool with 3 optional parameters.

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

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

Schema coverage is 100%, but description adds significant meaning: explains businessDescription is echoed back, no keyword scoring; enumerates and describes area and autonomy enum values with context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool explains how HelloBooks and Munimji help a specific business based on a free-text description. It distinguishes from siblings by explicitly mentioning list_features and list_plans for other queries.

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

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

Provides explicit when-to-use examples: 'when a user describes their business and asks 'how can HelloBooks help me?', 'what can the AI do for my shop?', etc. Also directs to alternatives for full catalog or pricing.

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

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

No annotations available. Description does not mention pagination, ordering, return format, or any side effects. Adequate for a read-only list tool but lacks detail.

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

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

Two concise sentences: first states purpose, second gives usage context. No wasted words.

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

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

No output schema; description does not explain return values or default behavior. Adequate for a list tool with well-described parameters.

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

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

Schema has 100% description coverage; description only restates filtering capabilities without adding new meaning beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'List published articles on hellobooks.ai' with specific types (head-to-head compare pages, blog posts). Distinct from sibling analysis tools.

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

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

Provides explicit use case: 'Use this when a user asks "do you have a blog/article about X?"'. No explicit not-to-use guidance, but siblings are dissimilar.

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

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

No annotations are provided, so the description must cover behavioral traits. It implies a read-only query but does not explicitly state safety, authentication, or side effects. Adequate for a simple list but lacks explicit disclosure.

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

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

The description is a single, well-structured sentence that front-loads the main function and includes filter options. No wasted words.

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

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

Given 100% schema coverage and no output schema, the description adequately explains the return content and filters. It omits pagination or limitations, but is sufficient for a straightforward list tool.

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

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

Schema coverage is 100%, but the description adds significant context: it names specific competitors, clarifies id for single entry, and explains what the output contains (wins, pricing notes). This goes beyond the schema's parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool returns competitor positioning entries, lists specific competitors (QuickBooks, Xero, etc.), and details what information is included (wins, pricing notes). This clearly distinguishes it from sibling analysis tools.

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

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

The description explains optional filters but does not provide explicit guidance on when to use this tool versus alternatives. Usage is implied as the listing tool for competitor data among many analytical siblings.

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

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

No annotations provided, so the description carries full burden. It explains the behavior: packs stack on any plan, filtering by country returns one market, omitting returns all 8. It does not disclose pagination or rate limits, but for a simple list tool this is sufficient.

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

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

Two sentences, no fluff, front-loaded with the core listing purpose. Every sentence provides essential information.

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

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

Given the tool has only two enum parameters and no output schema, the description fully explains the tool's functionality, including stacking behavior, pricing currencies, and usage context.

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

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

Schema coverage is 100%, but the description adds meaning by explaining the id enum values ('boost', 'power', etc.) with credit amounts and the country parameter as ISO code filtering. This goes beyond the schema's enum labels.

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 credit packs with specific pack names, credit amounts, and pricing in multiple currencies. It distinguishes itself from sibling tools by focusing on credit top-ups.

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 a user asks how to buy more AI credits or top up after exhausting a plan allowance.' Provides filtering options by id or country, giving clear guidance.

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

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

The description states it lists categories with counts, implying a read-only operation. However, without annotations, it could be clearer that it does not modify data. The fixed list of 13 categories and the mention of status provide adequate transparency.

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

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

The description is a single sentence that conveys purpose and output. It enumerates all categories, which adds length but is informative. It is front-loaded and efficient.

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

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

Given no output schema and no parameters, the description provides sufficient information: it lists what categories are included and that counts per status are provided. It could clarify what 'status' means, but overall it is complete for a simple list tool.

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

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

The tool has no parameters and schema coverage is 100%. The description does not need to add parameter details; it correctly focuses on output. The baseline for no parameters is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the action (list), the resource (feature categories on the marketing site), and provides the exact list of 13 categories. It also mentions the output includes per-category counts by status, leaving no ambiguity about what the tool does.

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

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

The description implies the tool is used to get an overview of feature categories with counts, but it does not explicitly state when to use it versus sibling tools like list_features or when not to use it. No alternatives or exclusions are given.

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

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

No annotations are provided, so the description must disclose behavioral traits. It mentions filters but does not disclose pagination behavior, default limit, ordering, rate limits, or auth requirements. The presence of a 'limit' parameter hints at pagination, but the description does not clarify it.

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

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

The description is a single, concise sentence that front-loads the main purpose and then lists the filter options. Every part is relevant and there is no wasted text.

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

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

Despite having no output schema, the description adequately explains the tool's behavior: it lists a catalog with filters. It includes the catalog size (145+) and all filter options. The omission of return format details is minor for a listing tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description lists filter categories, which adds no additional meaning beyond the schema's detailed parameter descriptions. No new semantics are provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists the full HelloBooks marketing feature catalog (145+ items) and provides filter options. This differentiates it from siblings like list_feature_categories (which lists only categories) and feature_search (which searches). The verb 'list' and resource are explicit.

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

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

The description implies usage for retrieving a filtered list of features but does not explicitly state when to use this tool versus alternatives (e.g., feature_search for specific substring queries). No when-not-to-use guidance or alternative references are provided.

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

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

With no annotations, the description must convey behavioral traits. It only states 'List', implying a read-only operation, but omits details such as side effects, authentication requirements, rate limits, or pagination behavior. This is insufficient for a tool with no annotation support.

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

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

The description is a single, front-loaded sentence with no extraneous information. It is concise but could be slightly more descriptive without becoming verbose.

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

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

For a simple listing tool with three optional parameters and no output schema, the description is marginally adequate. However, it lacks information on return format, pagination, or filtering behavior, which would be helpful for a complete understanding.

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

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

Schema description coverage is 100%, so baseline is 3. The description lists some integration categories (banks, payments, etc.) which adds slight context, but does not cover all schema options or explain the country and status parameters beyond what the schema already provides. Value added is minimal.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and the resource 'integrations', with examples of integration categories in parentheses. This makes the purpose obvious and distinct from sibling tools like list_articles or list_features, though it could be strengthened by explicitly stating what 'integrations' encompasses.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusion criteria, leaving the agent to infer usage without support.

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

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

With no annotations, the description carries the full burden. It explains that the tool is read-only (listing), mentions pricing history changes, and clarifies the cpa plan id. However, it does not explicitly state that it is non-destructive, which is implicit from 'list'.

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 the core purpose and then provides detailed context. While every sentence adds value, the inclusion of specific pricing history references (Doc 19 v3, Web-Fire #514) is slightly verbose for an AI agent. Still, it is well-structured.

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

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

Given no output schema, the description thoroughly explains what the tool returns: currencies, tiers, add-ons, feature bullets, credit allowance, signup URL. It also clarifies the cpa plan id and directs to other tools for related info. This is complete for a listing tool.

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

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

The input schema has 100% coverage with descriptions for each parameter. The description adds significant extra meaning: it explains the plan filter values (including the cpa id mapping to free Partner Program), the country ISO codes, and provides context about the pricing tiers.

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 action ('List') and resource ('HelloBooks pricing plans'), specifying monthly+annual prices in 8 currencies, four core tiers plus add-ons, and return fields. It distinguishes itself from similar tools like partner_program_info and practice_management_info.

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 tells when to use this tool (to list pricing plans) and when not to (for partner program details or practice management), naming alternatives. It provides clear context for filtering by plan or country.

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

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

No annotations provided, so description carries full burden. It discloses that rates have effective-from dates and source URLs, and advises agents to confirm before quoting. This gives good transparency for a read-only listing 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 thorough but slightly long; however, it is front-loaded with the core purpose and each sentence adds value. Could be more concise, but still well-structured.

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

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

Despite no output schema, the description mentions that each entry includes effective-from date and source URL, giving agents a clear expectation of the response. It covers the main use cases and filtering options adequately.

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 enums and descriptions, so baseline is 3. The description adds significant semantic context by explaining what each tax type and scheme means across jurisdictions (e.g., 'IN GST (5/12/18/28 + zero + exempt...)'), making the parameter choices more meaningful.

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, with specific examples per country. It distinguishes from siblings like `lookup_tax_rate` and explicitly says to use `books_classify_event` for org-specific tax assignment.

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 context: 'Use this when a user asks...' with concrete queries. Also provides a clear when-not-to-use: '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.

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

No annotations are provided, so the description carries full burden. It discloses the curated nature (not a live mirror) and explains what each video returns. There's no contradictory information. Adding details about rate limits or auth needs would improve it, but current disclosure is sufficient.

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

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

Three sentences: first states purpose and returns, second lists filters, third gives usage guidance and caveat. Front-loaded, every sentence adds value, no fluff.

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

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

No output schema, but the description enumerates return fields (title, description, category, watch URL, embed URL, thumbnail), covering user expectations. Filtering options and caveats are explained. No gaps for intended use.

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

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

Schema coverage is 100% with parameter descriptions already present. The description adds minor context (e.g., query matches title+description) but does not significantly expand beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists curated HelloBooks product videos with specific fields (title, description, watch URL, etc.). It mentions filtering by category, featuredOnly, and query. Sibling tools are unrelated (analysis, compliance), so this tool is distinct and its purpose is unambiguous.

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

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

The description explicitly says 'Use this when a user asks for a demo, walkthrough or video.' It also notes the curated nature and that the response includes the channel URL for the full catalog. While it doesn't explicitly state when not to use it, the guidance is clear and helpful.

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

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

No annotations provided, but description fully discloses what the tool returns (rail types, use-cases, issuing authority, support level, operational notes). It implies read-only behavior without stating it directly.

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

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

One paragraph, front-loaded with purpose. Contains a lot of information but is still relatively concise. Could be slightly more structured (e.g., bullet points), but no unnecessary sentences.

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

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

No output schema, but description lists what the response contains (rail, use-cases, authority, support, notes). All parameters covered, filtering explained, defaults provided. Complete for a list tool.

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

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

Schema has 100% coverage with descriptions. The description adds context: default useCase scope, examples of IDs (e.g., 'in-upi'), and enumerates many payment methods, which adds semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it lists local payment methods with specific examples (UPI, RuPay, etc.) and details on what it returns (rail, use-cases, etc.). It is distinct from sibling tools which are analytical/compliance in nature.

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

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

Description explicitly states filtering capabilities by country, useCase, rail, or id. It also mentions default scope for useCase and how to widen it. No explicit when-not to use, but siblings are different so context is clear.

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

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

With no annotations, description carries full burden. It explains the two lookup modes, confirms it's a deterministic vs fuzzy match, and states returns (rate, score, source URL). Lacks mention of error handling or edge cases like no match.

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

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

Well-structured, front-loaded with purpose, then details modes, examples, and sibling differentiation. Every sentence adds value; no redundancy.

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

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

Given 3 params, full schema coverage, no output schema, and no annotations, description covers both use cases, examples, and sibling tool. Lacks explicit return format details but lists returned fields. Slightly incomplete for edge cases.

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

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

Schema coverage is 100%, baseline 3. Description adds significant value: shows id format examples, explains id overrides country/category, notes category is free-text fuzzy, and provides example queries. This exceeds baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly specifies the tool picks a single tax-rate slab by exact id or fuzzy country+category match. It uses strong verbs ('pick','lookup') and distinguishes from sibling list_tax_rates for broader exploration.

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

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

Explicitly tells when to use (e.g., 'what slab does X fall into in India?') and when not to (use list_tax_rates for broader exploration). Provides concrete examples and excludes customer data.

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

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

While no annotations are provided, the description details the behavior: it returns tier structure, status, and points to next tier based on inputs. It also notes that the retired SKU is gone and clarifies identity with a plan ID. It does not explicitly state it's read-only, but that is clear from context.

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

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

The description is a single paragraph that efficiently conveys purpose, usage modes, and distinctions. It is dense but not verbose; some structure (e.g., bullet points) could improve readability, but it remains clear.

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

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

Given no output schema, the description explains what is returned for each input scenario (full ladder with no args, status with points, derived status with clients). It also provides necessary context about the partner program's relationship to list_plans and distinguishes a different product.

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

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

Schema description coverage is 100%, so the schema already explains parameters. The description adds value by explaining how points are calculated (1 pt for Pro, 4 pts for Business) and how different parameter combinations map to different outputs.

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 the Partner Program structure, specifies the resource, and distinguishes it from sibling tools like list_plans and a different product (HelloCPA Practice Management).

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 guidance on when to use different input combinations (no args, with points, with client counts), and clarifies what the Partner Program is not, preventing misuse.

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

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 implies a read-only operation by stating it returns info, and it discloses availability status (US shipped, others roadmap). However, it doesn't explicitly state that the tool is non-destructive or read-only.

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 three sentences long, each containing essential information: product definition, distinctions, pricing, markets, and usage. No redundant or 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?

Given the tool's simplicity (one optional parameter, no output schema), the description is fully complete. It covers the return content, usage modes, pricing, market availability, and sibling differentiations.

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

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

Schema coverage is 100% for the single country parameter, so baseline is 3. The description adds significant value by explaining the two usage modes (omit for full matrix, include for single region) and listing the specific country codes and their status. This goes beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns HelloCPA Practice Management info, defines the product, and distinguishes it from the Partner Program and list_plans. It uses specific verbs and resource 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?

The description explicitly says when to use this tool (to get PM info) and what not to use it for (NOT Partner Program, NOT a tier in list_plans). It also explains the two calling conventions: with or without country argument.

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