HelloBooks AI MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.5.0
Disambiguation5/5
Each tool has a clearly distinct purpose, from financial statement analysis (balance sheet, P&L, trial balance) to journal analysis per platform (QBO vs Xero), compliance, features, and comparisons. No two tools overlap in function; even similar tools are differentiated by data source or specific check.
Naming Consistency5/5
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.
Tool Count4/5
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.
Completeness5/5
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.
Average 4.3/5 across 26 of 26 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 42 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness3/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines5/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. 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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness3/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![HelloBooks-MCP-Public MCP server](https://glama.ai/mcp/servers/Meru-Fin-Tech/HelloBooks-MCP-Public/badges/card.svg)](https://glama.ai/mcp/servers/Meru-Fin-Tech/HelloBooks-MCP-Public)

Score Badge

Copy to your README.md:

[![HelloBooks-MCP-Public MCP server](https://glama.ai/mcp/servers/Meru-Fin-Tech/HelloBooks-MCP-Public/badges/score.svg)](https://glama.ai/mcp/servers/Meru-Fin-Tech/HelloBooks-MCP-Public)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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