Alberta Tax Agent

by chiKeka

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation2/5
Several tools have overlapping boundaries, such as the multiple logging tools (log_research, log_correction, log_task_insight) and multiple status/planning tools (tax_health_check, advisor_notes, filing_status). With 69 tools, even well-described tools become hard to distinguish, and some pairs like treaty_rate_lookup vs treaty_rates_table or holding_company_analysis vs reorganization_advisor require careful reading.
Naming Consistency2/5
Naming conventions are inconsistent, mixing verb_noun (record_transaction, calculate_corporate_tax), noun phrases (filing_status, corporate_tax_rates), and even full sentences (what_records_do_i_need). Some tools use adjectives (financial_summary) and others use acronyms (CCA, SR&ED) without a consistent pattern.
Tool Count1/5
With 69 tools, this server is far beyond the typical scope for an MCP server. The sheer number overwhelms an agent's selection capabilities and suggests many tools could be consolidated or removed. Even complex domains like tax rarely require 69 discrete tools.
Completeness5/5
The tool surface comprehensively covers the domain of Alberta business tax: setup, bookkeeping, imports, GST, payroll, corporate tax, compliance, planning, and a learning system. There are no obvious dead ends for core workflows, and even meta-tools for tracking knowledge gaps are included.
Average 3.7/5 across 69 of 69 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
With no annotations provided, the description bears full responsibility for disclosing behavior. It says 'Show' (implying read-only), but provides no detail about return format, whether all accounts are listed by default, or any limitations. The existence of a type_filter parameter is not mentioned, which is a notable omission.
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 two concise sentences, front-loaded with the main action ('Show the chart of accounts') and followed by meaningful context. Every word earns its place with no filler.
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?
This is a simple one-parameter tool, but the description omits any mention of the filtering capability offered by type_filter. It also does not describe what the output looks like (though there is no output schema). The contextual information about CRA tax lines is useful, but the missing parameter context makes it incomplete for the agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter understanding. It fails to mention the type_filter parameter at all. The parameter's enum values are not explained in the description, though the schema itself provides them. The description adds no value beyond what the schema already shows.
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's function: 'Show the chart of accounts used for bookkeeping.' It also adds context about mapping transactions to CRA tax lines, which distinguishes it from generic financial views. However, it does not explicitly differentiate it from sibling tools like financial_summary, so not a perfect 5.
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 is given about when to use this tool versus alternatives. The description only says 'Show the chart of accounts' but does not explain in what scenarios this would be the appropriate tool, nor does it mention any exclusions or preferred alternatives among the many sibling tools.
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?
No annotations are provided, so the description carries the full burden of explaining behavior. It only lists content topics (what to keep, how long, format) but does not disclose whether the output is a static document, how it processes the input parameters, or what the response looks like.
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?
A single, well-structured sentence that front-loads the core purpose. It is concise and wastes no words.
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?
Given the tool has 4 parameters, no output schema, and no annotation coverage, the description is too thin. It fails to explain how the parameters tailor the guide or how it differs from the similar sibling 'what_records_do_i_need'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its four parameters (business_type, has_employees, has_gst_registration, has_international_operations). The description does not mention any of these parameters or how they affect the guide, providing no added value over the bare schema.
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 it is a guide for CRA and Alberta TRA record keeping requirements, covering what to keep, how long, and in what format. However, it does not differentiate from the sibling tool 'what_records_do_i_need', which likely serves a similar purpose.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention 'what_records_do_i_need' or any other sibling, nor does it provide context for when this guide would be appropriate.
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, the description carries the full transparency burden. 'See' implies a read-only operation, but it does not disclose any behavioral traits such as return format, data source, whether the tool has side effects, auth requirements, or prerequisites. This is minimal disclosure beyond the basic read implication.
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 short and front-loaded with the core purpose. The second sentence 'Your accountant's status board' is somewhat decorative and does not add functional value, but the overall structure is concise and easy to parse.
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?
The tool has no output schema and no annotations, so the description should explain return values and parameter effects. It does mention the high-level output categories (filed, pending, overdue) but completely ignores the fiscal_year parameter and provides no details on how the dashboard behaves. For a tool with one optional parameter, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention the single parameter fiscal_year at all. It fails to explain the expected format, allowed values, or how omitting the parameter affects results. The description provides no additional meaning over the schema.
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 what the tool does: it shows filing statuses (filed, pending, overdue). The verb 'see' and resource 'status board' give a specific purpose, and it is distinguishable from siblings like financial_summary or missing_receipts, though it does not explicitly contrast with them.
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 phrase 'Your accountant's status board' implies when to use it—when you need an overview of filing statuses—but it does not explicitly say when not to use it or mention alternatives such as mark_filed or upcoming_deadlines. Usage is implied rather than clearly instructed.
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 available, the description bears the full responsibility for behavioral disclosure. It only states that the tool determines frequency and due dates based on average monthly withholding, without revealing assumptions, underlying rules (e.g., CRA regulations), or potential limitations. This leaves the agent guessing about the calculation logic.
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, concise sentence that is front-loaded with the main action and resource. Every word earns its place, and there is no unnecessary detail or repetition.
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?
The tool has three parameters and no output schema, so the description is the primary source of context. It fails to explain the expected output format, how inputs influence the schedule, or any edge cases (e.g., new employers, compliance history). This lack of context makes the tool behavior unpredictable for the agent.
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?
All three parameters are fully documented in the schema with descriptions, achieving 100% schema_description_coverage. The description itself adds no additional parameter-specific meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (determine) and the resource (employer's payroll remittance frequency and due dates), making the tool's purpose evident. It does not explicitly distinguish from sibling tools like 'calculate_payroll' or 'upcoming_deadlines', but the purpose is specific enough to avoid major ambiguity.
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 is provided about when to use this tool versus alternatives. The description implies it is used when remittance schedule information is needed, but it does not mention any exclusions, prerequisites, or context that would help the agent choose between this and related tools.
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 is the sole source of behavioral information. The verb 'look up' and 'shows' imply a read-only operation, but no other behavioral details are disclosed, such as error handling for invalid country codes, data source, or return format. The inclusion of 'management fees' which is not in the payment_type enum could mislead about available parameters.
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 a single, front-loaded sentence with no filler. However, the author chose to list 'management fees' which is not a valid payment_type, adding a misleading detail that detracts from the otherwise efficient structure.
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?
Despite the simplicity of the tool, the description lacks essential context: it does not describe the return format, default behavior, or how to request all rates (payment_type default), and the enumeration of payment types is inconsistent with the schema. Given no output schema and no annotations, the description is insufficient for an agent to reliably predict the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema, so baseline is 3. The description does not add meaningful syntax or behavior beyond the schema, and actually introduces an unsupported category ('management fees') not present in the payment_type enum, potentially confusing the agent. Country_code is only paraphrased as 'specific country' with no additional detail.
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 looks up Canada's tax treaty withholding rates for a specific country, with a specific verb ('look up') and resource. It names concrete rate categories (dividends, interest, royalties, management fees), which helps distinguish from generic tax tools. However, it does not explicitly differentiate from sibling tools like treaty_rates_table.
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 is given on when to use this tool versus alternatives such as treaty_rates_table, foreign_tax_credit, or cross_border_transaction. The description only states what it does without specifying conditions, prerequisites, or exclusions.
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 provided, the description carries the full burden of disclosing behavioral traits. It implies a read-only operation but never explicitly states it, nor does it mention side effects, default filtering behavior, or return format. The line about 'flagged that need your attention' adds context but not sufficient safety or outcome clarity.
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 two sentences, front-loaded with the primary action, and contains zero wasted words. Every phrase contributes meaning, making it appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple view tool with one optional parameter and no output schema, the description is adequate but incomplete: it doesn't clarify whether resolved notes are hidden by default (though schema implies false), doesn't state that the tool is read-only, and doesn't describe the output type. These gaps prevent a higher score, but the tool's simplicity keeps it at a minimally viable level.
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?
The single parameter 'show_resolved' is fully described in the schema (100% coverage) with the question 'Include resolved notes?', so the description need not repeat it. The description adds no extra semantic detail beyond the schema, making the baseline 3 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 uses a clear verb ('See') and specific resource ('all my notes, reminders, and action items'), making the tool's purpose obvious. While it doesn't explicitly distinguish from siblings like 'resolve_note', the focus on viewing advisor-flagged items is unique enough to warrant a 4.
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 is provided on when to use this tool versus alternatives. The description implies usage for viewing flagged items but lacks explicit context, exclusions, or mention of related tools like 'resolve_note'.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the tool provides a 'complete checklist' but does not explicitly mention whether it returns a list, whether it is read-only, or whether it has any side effects. Given the no-parameter, simple nature, the behavior is implied but not clearly disclosed.
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, front-loaded sentence that immediately states the tool's purpose and key content. It is concise, contains no fluff, and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters, no output schema, and no annotations, the description is adequate but thin. It specifies the scope (Alberta employers) and examples, but does not explain the output format or whether it is a static reference or an interactive checklist. The 'and more' is vague, leaving some ambiguity about the full scope.
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?
There are zero parameters, so per the baseline rule, this dimension scores 4. The description does not need to explain parameters, and it does not add any misleading parameter-related information.
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 identifies the tool as a checklist for annual employer obligations in Alberta, with specific examples (T4s, ROEs, WCB). It distinguishes itself from sibling tools by focusing on employer-specific annual duties rather than general year-end or tax preparation checklists. However, it lacks an explicit action verb like 'generate' or 'view', making it slightly less direct.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention related tools such as year_end_checklist or filing_calendar, nor does it state any exclusions or conditions. The agent is left to infer usage context solely from the tool name.
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 provided, the description carries the full burden of behavioral disclosure. It reveals the rate assumption and input modes, but does not specify the return value format, rounding behavior, or side effects. This is a notable gap because the tool likely performs a pure calculation and could easily state that it returns GST amount and total.
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 two concise sentences with no filler. The first sentence states the core purpose, and the second provides essential usage context about input modes and the applicable tax rate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter calculator with no output schema and no annotations, the description is mostly adequate but omits return value details (e.g., does it return just the GST amount, the total, or both?). This ambiguity plus the lack of side-effect disclosure leaves the description incomplete for an agent to fully anticipate the tool's 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 description coverage is 100% with both parameters documented, so the baseline is 3. The description restates the inclusive/exclusive distinction and adds the Alberta rate context, but does not significantly extend parameter semantics beyond what the schema already explains.
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 uses a specific verb and resource ('Calculate GST on a transaction') and clearly states its scope. It distinguishes from siblings like gst_quick_method_analysis by focusing on a simple transaction calculation, though it does not explicitly name alternatives.
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 gives usage context ('Can work from GST-exclusive or GST-inclusive amounts', 'Alberta rate is 5% (no PST/HST)') but does not explicitly state when to use this tool versus alternatives such as prepare_gst_worksheet or gst_quick_method_analysis. The usage is implied rather than guided.
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?
Given no annotations, the description carries full responsibility for disclosing behavioral traits. The word 'Estimate' hints at a computation, but the description does not state whether the tool is read-only, what assumptions or formulas are used, whether it persists data, or what side effects (if any) occur. No return format is described.
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, front-loaded sentence that conveys the essential purpose without unnecessary filler. It is appropriately sized for a simple calculation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward calculator with well-documented parameters, the description covers the core purpose but omits behavioral context such as whether the result is an estimate only, any limitations, or what the output looks like. Since there is no output schema, a brief note on the return value 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 the baseline is 3. The description adds a high-level link between payroll and industry classification, which clarifies the role of industry_rate_per_100, but it does not provide additional details about parameter syntax, units, or calculation logic beyond what the schema already gives.
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 a specific verb ('Estimate') and resource ('Workers' Compensation Board (WCB) Alberta premiums'), with a clear basis ('payroll and industry classification'). It distinguishes itself from sibling tools like calculate_payroll or calculate_corporate_tax by naming a unique calculation target.
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 is provided on when to use this tool versus alternatives. While the name and description imply it is for WCB Alberta premium estimation, there is no mention of prerequisites, exclusions, or situations where other tools would be more appropriate.
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 provided, the description carries the full burden for behavioral disclosure. It only mentions 'Show' (implying read-only) but does not explicitly state that it makes no changes, how 'missing receipts' is determined, or whether there are any side effects or prerequisites. The CRA comment is motivational, not behavioral.
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 two sentences, front-loaded with the primary action, followed by a concise rationale. Every word contributes value, and there is no fluff or repetition.
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?
For a tool with one parameter, no output schema, and no annotations, the description is too sparse. It lacks any information about the fiscal_year parameter's format/necessity, what the output looks like, and whether the operation is read-only. The tool's simplicity lowers the bar, but the missing parameter guidance and behavioral clarity make it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented fiscal_year parameter. It fails to mention the parameter at all, leaving the agent to guess the format (e.g., '2024' vs '2024-12-31') and whether the tool filters by year or requires it. This is a significant gap.
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 function: 'Show all transactions that are missing receipts.' This is a specific verb+resource structure that distinguishes it from sibling tools like record_receipt or scan_receipts_folder, which are about adding/scanning receipts rather than reporting missing ones.
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 context by adding 'CRA can deny deductions without proper documentation,' suggesting it's useful for tax preparation. However, it does not explicitly say when to use this tool versus alternatives like tax_health_check or what_records_do_i_need, nor does it provide any exclusion criteria.
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?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not state that this is informational advice only, mention jurisdiction/legal limitations, describe the form of output, or note any prerequisites such as having financial data. The description is purely functional with no caveats.
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, front-loaded with the tool's purpose and enriched with specific section references. No wasted words; the description is well-structured for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is an advisor with four parameters and no output schema or annotations; the description provides a reasonable high-level purpose but lacks caveats, expected response format, and any guidance on limitations or prerequisites. It is minimally viable but leaves gaps for an agent deciding whether this tool fits a complex advisory use case.
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 schema already documents all four parameters. The description adds general context about reorganization types but does not map them to specific parameter values (e.g., which scenario corresponds to a butterfly transaction), nor does it explain how has_tax_losses or num_corporations affect the advice. Baseline 3 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 identifies the tool's domain: guidance on corporate reorganizations with specific transaction types (amalgamation, wind-up, butterfly, rollover). It uses a specific verb ('Guidance') and resource, but does not explicitly distinguish it from sibling tools like holding_company_analysis or estate_freeze_planner, which could overlap.
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?
It implies usage when the user needs to choose a corporate restructuring structure ('Identifies the right structure for your situation'), but provides no explicit when-to-use, when-not-to-use, or alternative tool suggestions. Sibling tools could serve adjacent purposes but are not mentioned.
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 of behavioral disclosure. It states that the tool displays rates, which implies a read-only operation, but it does not describe the output format, any coverage limitations, or clarify the ambiguous parenthetical. This is a basic but not richly transparent description.
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 a single, front-loaded sentence that efficiently states the tool's purpose. The parenthetical addition adds some ambiguity, which slightly detracts from the otherwise concise structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema, so the description is mostly sufficient. However, the meaning of 'major trading partners' is unclear, and the description does not describe the output format or explicitly confirm that it returns a complete reference table. These gaps lower the completeness score.
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?
There are zero parameters, and the schema is empty, so no parameter information is needed. The description adds no parameter semantics, but with no parameters, the baseline score is 4.
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 uses a specific verb 'Display' and identifies the resource 'withholding tax rates for all countries' in Canada's tax treaty network, which clearly distinguishes it from the sibling 'treaty_rate_lookup'. However, the parenthetical '(major trading partners)' creates ambiguity about whether the table covers all treaty countries or only a subset, slightly reducing 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?
The description provides no explicit guidance on when to use this tool versus alternatives like 'treaty_rate_lookup'. While the scope 'all countries' implies an overview use case, there is no stated when-to-use/when-not-to-use or mention of alternatives.
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 provided, the description carries the full burden of behavioral disclosure. It only says 'compare tax implications' and 'critical', but does not explain what the tool computes or returns, any assumptions (e.g., Canadian tax context hinted by LCGE and QSBC fields), or limitations. This leaves significant behavioral gaps for a complex comparison 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 two sentences, front-loaded with the main verb and object. The second sentence about buyer/seller relevance adds useful audience context without excessive fluff. There is no wasted wording or redundant restatement of the tool name.
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?
This is a complex comparison tool with 8 input parameters and no output schema or annotations. The description does not mention expected outputs, calculation approach, jurisdictional specifics (e.g., Canadian tax concepts like LCGE and QSBC), or any caveats. Such sparse context is insufficient for an agent to understand what will happen when invoking the 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?
The input schema provides 100% coverage with descriptions for all 8 parameters, so the baseline is 3. The tool description itself adds no parameter-level meaning beyond the general context of asset vs share sale, so it does not elevate the score.
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 function: compare tax implications of asset sale versus share sale. It uses a specific verb and resource, and the focus on asset/share sale comparison distinguishes it from sibling tools like salary_vs_dividend or holding_company_analysis.
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 considering a business sale as an asset or share sale, and it notes relevance for both buyers and sellers. However, it does not explicitly state when to use over alternatives or provide exclusions or prerequisites, so the guidance is only implied.
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?
No annotations are present, so the description carries the full transparency burden. It lists features but does not reveal calculator behavior, assumptions, return format, or any side effects. It adds no behavioral context beyond what the schema already provides.
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 exactly two sentences, front-loaded with the primary action, and contains no redundant information. Every phrase adds value.
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?
With 11 parameters and no output schema, the description leaves significant gaps: it does not explain what the calculator returns, what assumptions underlie the calculation, or how the handling of CCA and benefits affects inputs. The schema covers parameter descriptions but not overall behavior or output.
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?
All 11 parameters have individual descriptions in the schema (100% coverage), so the baseline is 3. The description adds high-level context about CCA and benefits but does not map these to specific parameters or provide additional parameter-level nuance.
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 opens with a clear action and resource: 'Calculate deductible vehicle expenses for business use.' It then lists specific areas handled (CCA, standby charges, operating benefits, per-km allowances), which distinguishes it from related tools like calculate_cca or calculate_home_office.
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 provides a clear context for use (business vehicle expenses) but does not explicitly state when not to use it or mention alternative tools. Guidance is implied rather than explicit.
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, the description carries full burden. It indicates factors considered (tax rates, liability, compliance costs, planning opportunities) but does not disclose what the tool returns (e.g., a comparison report, recommendation), whether it is strictly advisory/read-only, or whether any inputs trigger additional behavior. This lack of output clarity is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, front-loaded with the core purpose, and includes key factors in a compact, readable manner. No unnecessary words or repetition.
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?
Given the tool has six parameters, no output schema, and no annotations, the description is underspecified. It fails to explain what the user receives (e.g., a comparison matrix, pros/cons list, recommendation), how the inputs like expected_annual_income and personal_spending_needs influence the comparison, or what 'planning opportunities' means in context. More detail is needed for a 6-parameter advisory 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 description coverage is 100%, so the baseline is 3. The description does not add parameter-specific context beyond what the schema already provides, and it references only general factors, not the six specific inputs.
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 compares sole proprietorship, partnership, and corporation specifically for Alberta, which is a specific verb+resource. It distinguishes itself from sibling tools like salary_vs_dividend or holding_company_analysis by focusing on entity type selection.
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 implied usage is clear: when a user needs to compare business entity types. However, it does not explicitly mention when not to use it or point to alternatives, such as salary_vs_dividend for compensation planning or holding_company_analysis for corporate restructuring. It relies on the tool name and context.
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?
Given no annotations are provided, the description carries the full burden. It correctly implies a read-only operation via the verb 'Display' and describes the output structure (deadlines by category), but it does not disclose any caveats such as data source, update frequency, or whether the calendar is for a specific tax year.
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, front-loaded sentence with no extraneous information. It efficiently conveys the tool's scope and output organization.
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, single-parameter display tool, the description is mostly complete. It specifies the audience (Alberta businesses), the scope (annual), and the organization (category). It could be improved by stating what the returned output looks like (e.g., dates and deadlines), but the lack of an output schema reduces the burden.
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?
The input schema fully documents the single 'category' parameter with an enum and a clear description ('Filter by category or show all'). The description's mention of 'organized by category' aligns with the schema, so the description adds no significant meaning beyond the schema.
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 identifies the tool's function: displaying a complete annual tax filing calendar for Alberta businesses, organized by category. It uses a specific verb and resource, and the scope ('Alberta businesses', 'annual') helps distinguish it from related tools like 'upcoming_deadlines', though it doesn't explicitly name alternatives.
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?
The description provides no guidance on when to prefer this tool over the sibling 'upcoming_deadlines' or other calendar-related tools. It only describes what the tool does, not when it should be used or when an alternative is more appropriate.
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, the description carries the full burden for behavioral disclosure. It only says the tool 'identifies which strategies are available', but does not disclose return format, safety (read-only vs. write), assumptions, or limitations. The description adds minimal behavioral context beyond the core purpose.
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, leading with the primary verb, and no redundant information. It is appropriately sized and front-loaded with the key purpose, making it easy to scan.
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?
For an advisor tool with no annotations and no output schema, this description is incomplete. It does not explain what the output looks like, how strategies are presented, or what assumptions are made. The tool has moderate complexity (nested family_members array) and would benefit from clarifying intended use and result format.
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 meaning to family_members by mentioning 'ages and involvement', but does not clarify the impact of over_90pct_service_income or corporation_is_professional. Overall, the description adds marginal value over the already thorough 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 analyzes income splitting opportunities while considering TOSI rules, using specific verbs 'Analyze' and 'Identifies'. It differentiates from sibling tools like salary_vs_dividend by focusing on TOSI compliance and family member specifics (ages and involvement).
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 income splitting with TOSI concerns is needed, but it provides no explicit when-to-use vs. alternatives, no exclusions, and no named alternative tools. It leaves the agent to infer context from the TOSI mention, which is a clear signal but not explicit guidance.
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 provided, the description carries the full burden of behavioral disclosure. It only states what the tool calculates and the scenarios covered, but does not mention whether the calculation is an estimate, whether it modifies data, what the output format is, or any assumptions/limitations. For a calculator, this lack of detail leaves the agent uncertain about side effects and return behavior.
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 two short sentences, front-loaded with the main purpose. It is concise, clear, and contains no filler. Every word contributes to understanding the tool's scope and scenarios.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no output schema, and no annotations, the description is adequate but not complete. It explains the general purpose but does not describe the output (presumably a deduction amount) or any calculation assumptions. It also doesn't mention whether the tool provides a breakdown for both scenarios simultaneously or requires separate calls. There is a clear gap in behavioral context that could affect correct usage.
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 parameter-specific meaning beyond the schema; it only says 'Covers both self-employed and corporate scenarios,' which indirectly relates to boolean parameters but does not clarify how they affect the calculation. The schema itself already documents all 11 parameters, so the description adds minimal 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?
The description clearly states the tool's function: 'Calculate the business deduction for using a home office.' It identifies the resource (home office) and the action (calculate deduction), and distinguishes it from other calculation tools by specifying 'Covers both self-employed and corporate scenarios.' This makes the purpose unambiguous and differentiated from sibling calculators like calculate_vehicle_expense.
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 by specifying the tool's domain ('home office') and scenarios (self-employed/corporate), but it does not explicitly state when to use this tool over alternatives or provide exclusions. There is no mention of prerequisites or conditions, leaving the 'when to use' guidance implicit rather than explicit.
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, the description carries the full burden of behavioral disclosure. It states it's a 'step-by-step guide' but does not explain what the output looks like, whether it customizes based on parameters, or any side effects. There's no context beyond the basic process scope, leaving the agent guessing about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 core purpose and uses an em-dash to add scope detail. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately conveys the tool's purpose and scope for a simple guide, but it lacks specifics about how the input parameters affect the output or what the returned guidance will look like. Without an output schema or annotations, a bit more detail would make the tool more predictable.
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?
The input schema already provides 100% coverage with clear descriptions for all three parameters. The description adds no additional parameter-level meaning, so the baseline of 3 applies.
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 provides a step-by-step guide for disputing a CRA assessment, specifying the process from Notice of Objection through Tax Court. This is a specific verb+resource combination that distinguishes it from sibling guides like voluntary_disclosure_guide.
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 when to use the tool (when disputing a CRA assessment) but provides no explicit alternatives or exclusions. It doesn't clarify how it differs from other guides like voluntary_disclosure_guide, so usage guidance is implied rather than explicitly stated.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the purpose, without mentioning that the tool considers special rules like taxi/rideshare status or a single-quarter threshold, nor does it indicate what the output looks like or whether the operation is side-effect-free. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant information. It is front-loaded with the key verb and purpose, making it immediately clear what the tool does. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description is adequate but minimal. It states the core purpose but does not mention the factors that influence the assessment (taxi/rideshare, single-quarter threshold) or hint at the output format. The schema fills parameter details, but the description alone leaves some gaps for an agent predicting 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 description coverage is 100%, so the baseline is 3. The description adds minimal meaning beyond the schema by mentioning 'revenue level' (corresponding to annual_taxable_supplies), but it does not elaborate on the other parameters (is_taxi_rideshare, quarterly_revenue_highest). Since the schema already thoroughly describes all parameters, the description does not need to compensate much, but it also adds little.
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 ('Determine') and clearly identifies the resource (GST registration requirement and optimal filing frequency) and input basis (revenue level). This distinguishes it from sibling tools like calculate_gst, which focuses on computing GST amounts, making the purpose unambiguous.
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 to assess registration requirements and filing frequency, but it does not explicitly contrast with alternatives or state when not to use this tool. The context 'based on your revenue level' provides some guidance, but no explicit exclusions or alternative references are given.
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 provided, the description carries the full burden of behavioral disclosure. It only states that the action 'Updates your filing status tracker,' which is minimal. It does not disclose whether the action is irreversible, whether it overwrites existing data, requires specific permissions, or what the response will be. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, directly to the point, with no fluff or redundancy. Every word earns its place, and it is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and the schema fully documents parameters. However, there is no output schema, and the description does not explain what the tool returns or how success is indicated. Given the simplicity, the description is adequate for basic invocation but lacks completeness for understanding the full response 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?
The schema description coverage is 100%, with all four parameters clearly documented in the input schema. The description adds no additional meaning to the parameters, so the baseline score of 3 is appropriate. It does not explain parameter relationships or edge 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's action: 'Mark a tax return as filed.' This is a specific verb+resource combination that distinguishes it from sibling tools like filing_status (which is likely for viewing status) and preparation tools. The addition 'Updates your filing status tracker' reinforces the purpose.
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 when to use the tool (after filing a return, to update tracking) but does not explicitly state when not to use it or mention alternatives. No exclusions or distinct scenarios are provided.
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 provided, the description carries the full burden of behavioral disclosure. It states the primary effect (marking resolved) but does not disclose idempotency, reversibility, permissions, or what happens if the note is already resolved. This is a minimal description that leaves important behavioral questions unanswered for a state-changing operation.
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, front-loaded sentence that conveys the essential action without any superfluous words. It is optimally concise and well-structured for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is minimally adequate. It tells the agent what the tool does and what input is required, but it does not address edge cases (e.g., already-resolved notes) or the meaning of 'resolved' in the broader workflow. This is a viable but incomplete description.
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 for the single parameter is 100% ('The note ID to resolve'), so the baseline is 3. The tool description adds no additional parameter-level semantics beyond what the schema provides. It does not clarify formats, sources, or validation rules, but the schema is sufficient.
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 ('Mark...as resolved') and identifies the resource ('advisor note/action item'), clearly distinguishing it from sibling tools like 'advisor_notes' (which likely lists notes) and 'resolve_insight' (which resolves a different entity). The purpose is immediately evident.
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 you need to resolve a note—but it does not explicitly state when to use this tool versus alternatives like 'resolve_insight' or mention any exclusions. Since the context is straightforward and the action is clear from the name, it meets the 'implied usage' level but lacks explicit guidance.
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 provided, the description carries full responsibility for behavioral disclosure. It only mentions the calculation methods, but fails to describe return format, assumptions (e.g., whether the small CCPC flag changes the schedule), or side effects. The agent is left uncertain about what the tool actually produces or how it handles the combination method.
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, front-loaded sentence that conveys the core function and method options without unnecessary words. It earns its place with no redundancy or filler.
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?
For a calculator with 4 parameters and no output schema, the description is incomplete. It does not explain what the returned instalment amounts look like (e.g., a schedule, a breakdown by period), how the method is selected automatically, or how the small CCPC flag alters the result. The absence of output schema means the description should compensate, but it does not.
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 full descriptions for all 4 parameters (100% coverage), so the baseline is 3. The description adds value by explaining the three calculation methods (current-year, prior-year, combination) that map to the parameters, clarifying how current_year_estimated_tax, prior_year_tax, and second_prior_year_tax interact. This goes beyond the schema's individual parameter 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 action ('Calculate'), the subject ('corporate tax instalment amounts'), and the scope ('monthly/quarterly', with three specified methods). This is a specific verb+resource pairing that distinguishes it from sibling tools like calculate_corporate_tax, which likely focuses on total tax rather than instalments.
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 instalment amounts are needed) but does not explicitly state when to use this tool over alternatives or mention any exclusions. There is no guidance on prerequisites or comparison with sibling calculators, so the context is clear but not fully actionable.
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, the description carries full burden. It states the tool calculates, implying a read-only operation, but does not disclose output format, assumptions, or side effects. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and scope without any extraneous text.
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?
The tool has no output schema, and the description does not explain what the calculator returns (e.g., penalty amount, interest, total). It also omits assumptions like repeat offender multipliers. This makes the description incomplete for a calculation 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 description coverage is 100%, and the description adds no additional parameter context. Baseline 3 is appropriate as the schema already documents each parameter.
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 action (calculate), the resource (CRA penalties and estimated interest), and the scope (T2, AT1, or GST returns). This distinguishes it from sibling tax calculators.
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 use for late filing penalty calculations but provides no explicit guidance on when to choose this over alternative tax calculation tools. However, the context is unambiguous given the title and sibling set.
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?
No annotations are provided, so the description carries the full burden. It states the tool 'Analyze' and 'Covers' certain topics, but does not disclose what the output looks like, whether it is a calculation or guidance, any assumptions, or limitations. This is a significant gap for a tax analysis tool, leaving the agent unsure of what to expect.
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 core purpose and then lists the coverage areas. Every word earns its place, with no repetition of schema details or fluff.
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?
Despite having 5 parameters and no output schema, the description does not explain what the tool returns (e.g., a report, a numeric result, specific rates) or how to interpret the analysis. It also fails to mention any prerequisites or limitations. For a complex tax analysis tool, this leaves significant gaps in the agent's ability to use it 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 description coverage is 100%, so the schema already documents all parameters. The description adds no additional parameter-level meaning beyond listing the covered topics, which indirectly maps to some parameters (e.g., transaction_type, country_code, is_related_party). Baseline 3 is appropriate as the schema does the heavy lifting.
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 ('Analyze') and names the resource ('tax implications of a cross-border transaction'), with a clear scope between a Canadian company and a foreign entity. It lists the covered areas (withholding tax, transfer pricing, thin cap, treaty benefits), which distinguishes it from more targeted sibling tools like treaty_rate_lookup or foreign_tax_credit.
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 provides clear context: use when you need to analyze tax implications of a cross-border transaction between a Canadian and foreign party. It does not explicitly name alternative tools or state when not to use it, but the scope is clearly implied by the listed coverage areas and the tool's title.
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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions that insights 'drive improvements,' implying persistence, but it doesn't disclose permissions, reversibility, whether it appends or overwrites, or what the response looks like. For a write operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core action. The three sentences are purposeful, and the examples are valuable. It could be slightly tighter, but it's efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters and no output schema, but the schema covers all parameters. The description gives valuable context about why logging matters and what kinds of insights to record. However, it doesn't address relation to sibling tools like resolve_insight, potential failure modes, or return values, leaving some gaps for an agent.
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%, so the baseline is 3. The description provides examples of insight content ('partnership allocation not supported') that illustrate the 'insight' parameter, but it doesn't go beyond the schema to explain parameter relationships or edge cases. It neither compensates nor detracts, so a 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 opens with 'Record what was learned while performing a task,' which is a specific verb+resource combination. It then clarifies the tool's unique scope—tracking capability gaps, poor scenarios, and patterns—distinguishing it from siblings like log_research and log_correction. The examples further reinforce its purpose.
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 this tool: 'Use this to track gaps in the agent's capabilities, scenarios it hasn't handled well, or patterns it should recognize in the future.' This provides clear context, though it doesn't name alternatives or state when not to use it, so it stops short of a 5.
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 burden. It discloses that the tool checks records, flags problems, and tells what needs attention, implying a read-only review. However, it does not explicitly state that it does not modify data, nor does it mention any limitations or data sources. This is minimal but non-contradictory behavioral disclosure.
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 two sentences, front-loaded with the primary action, and uses a relatable metaphor. There is no redundant or repetitive content; every word contributes to understanding the tool's purpose and behavior.
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 simplicity (one optional parameter, no output schema, no annotations), the description provides sufficient context: it states the review scope, the action taken, and the nature of the output ('tell you exactly what needs attention'). It could be more specific about output format (e.g., a list or report) but is adequate for the tool's low 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 description coverage is 100% and the only parameter (fiscal_year) is well-described in the schema with default behavior. The tool description adds no parameter-specific detail beyond what the schema already documents, so the baseline of 3 applies.
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 action ('Run a comprehensive review') and the resource ('your business's tax situation'), and mentions what it does ('flag problems, and tell you exactly what needs attention'). It does not explicitly distinguish from siblings like audit_risk_assessment or financial_summary, so it falls short of a 5.
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 for a broad, periodic check ('like a quarterly meeting with your accountant'), but does not provide explicit when-to-use vs alternatives or exclusions. The sibling list includes overlapping tools like audit_risk_assessment, but no alternative is named or contrasted.
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 provided, the description carries full burden for behavioral disclosure. It only mentions that the guide covers General and Limited tracks, but does not explain that the tool likely uses the input parameters (e.g., estimated_unreported_income, type_of_issue) to tailor the response. There is no description of what the user will receive (e.g., eligibility assessment, next steps) or how the guide behaves beyond being a static text.
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 two sentences, front-loaded with the core purpose and including the key differentiator (both tracks). Every word earns its place, and the structure is clean and scannable.
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?
The tool has five parameters including sensitive financial inputs, and no output schema or annotations. The description is too brief to explain how the guide uses these inputs, what kind of output it produces, or what specific information it will cover beyond the two tracks. Given its moderate complexity, the description leaves significant gaps for an agent trying to invoke it 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 description coverage is 100%, so the schema already documents all five parameters with meaningful descriptions. The tool description adds no additional semantic context about how the parameters influence the guidance, but with full schema coverage, the baseline of 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 is a guide to CRA's Voluntary Disclosure Program, specifying its purpose (correcting past tax errors/omissions) and context (before CRA contacts you). It also distinguishes from sibling guides by naming the General and Limited tracks, making it unequivocally about VDP.
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 gives a clear 'when' to use the tool: when a client needs to correct past tax issues before CRA initiates contact. It does not explicitly name alternative tools or provide 'when not' conditions, but the trigger scenario is obvious and sufficient for basic differentiation from sibling resources like dispute_resolution_guide.
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 carries the behavioral burden. It indicates a checklist output and a planning purpose, but it does not disclose whether it is purely informational, how personalized the results are, or how the input parameters affect the checklist.
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 concise and front-loaded with the tool's purpose. However, the first sentence largely restates the title, leaving the second sentence to add meaningful context.
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?
With no output schema or annotations, the description needs to cover behavior and parameters more fully. It does not explain what the checklist contains or how the boolean inputs alter the output, making it incomplete for a 5-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 2 of 5 parameters have schema descriptions (40% coverage), and the description adds no details about is_ccpc, has_employees, or has_investments. It indirectly reinforces fiscal_year_end and estimated_income through 'year-end' and 'minimize taxes,' but this is insufficient.
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: a comprehensive year-end tax planning checklist for Alberta businesses, with the goal of minimizing taxes before fiscal year-end. This distinguishes it from other checklist tools like employer_annual_checklist.
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 communicates when to use the tool: before fiscal year-end for Alberta businesses. It does not name alternative tools or state exclusions, but the context is unequivocal.
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, the description must convey behavioral traits, but it only says 'Add...' without disclosing side effects, permission requirements, or how existing data (e.g., ownership percentages) might be affected. There is no mention of validation or response behavior, leaving the agent with limited understanding of the mutation's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the action, the second provides motivating use cases. It is concise, front-loaded, and contains no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema is rich and the description identifies key use cases, the absence of annotations and output schema leaves gaps. The description does not mention what happens after adding an owner (e.g., profile changes, recalculations) or any constraints on ownership percentages. For a mutation tool, this is minimal but not entirely inadequate given the schema's good parameter descriptions.
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?
The schema provides full descriptions for all 7 parameters, so the baseline is 3. The description does not add any detail about parameter semantics—it only mentions the high-level purpose. The schema already covers parameter meaning, so this dimension is adequately served.
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 action: 'Add an owner, shareholder, or partner to the business profile.' It identifies the resource being modified and is distinct from sibling tools like update_profile or setup_business. The mention of specific use cases (salary/dividend planning, income splitting, LCGE planning) further clarifies its role.
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 provides explicit context for when to use this tool: 'I need this for salary/dividend planning, income splitting analysis, and LCGE planning.' This gives clear guidance on usage scenarios, though it does not explicitly state when not to use it or name alternative tools.
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 calculation scope and key tax concepts (SBD, passive income grind, clawback), which adds useful context. However, it does not explicitly state that this is a read-only calculation, what assumptions are made (e.g., current tax rates), or limitations (e.g., applies only to Alberta). The verb 'calculate' suggests non-destructive behavior, but details are incomplete.
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 two sentences, front-loaded with the core action and resource, and each sentence adds value. It efficiently conveys both the primary purpose and the key tax components without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no output schema, and no annotations. The description explains the calculation scope and covered concepts, but does not specify the return format (e.g., single amount vs breakdown) or any edge-case assumptions. For a complex calculation tool, this leaves the agent uncertain about what to expect from the result.
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 does not add new parameter-level details beyond the schema, though it references concepts like 'passive income grind' and 'taxable capital clawback' that map to prior_year_passive_income and taxable_capital, respectively. This provides slight enrichment but no syntax or format additions.
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 'Calculate combined federal + Alberta corporate income tax' with specific scope (CCPC or other corporation) and lists key components (SBD, general rate, investment income, passive income grind, taxable capital clawback). This distinguishes it from sibling tools like corporate_tax_rates (rates only) and calculate_business_limit (SBD limit only).
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 for computing total corporate tax liability but does not explicitly state when to use this tool versus alternatives like corporate_tax_rates or calculate_instalments. There is no mention of exclusions or alternative tools, so the usage context is implied rather than explicit.
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 must disclose behavioral traits. It specifies the Alberta scope and that it shows both employee deductions and employer costs, but does not mention side effects, required permissions, tax year assumptions, or limitations (e.g., no Quebec support). This is partial transparency.
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 two concise sentences, front-loaded with the action and includes the key output differentiator (employer costs). No filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema, the description provides a basic output summary, but lacks guidance on parameter alternatives, tax year assumptions, or how to combine parameters (e.g., using annual_salary). The schema covers parameter definitions, yet the description does not tie them to the deduction logic.
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?
The input schema already documents all 4 parameters with 100% coverage, so the baseline is 3. The description adds no additional meaning about parameter relationships (e.g., gross_pay vs annual_salary) or how they map to the deduction types.
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 calculates CPP, EI, federal and Alberta income tax deductions, with a specific verb (Calculate) and resource (payroll deductions). It distinguishes itself from sibling tools like corporate tax or WCB by naming the exact deduction types and the employer cost output.
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 use when calculating payroll deductions for employees, but provides no explicit 'when to use' or 'when not to use' guidance, nor does it mention alternatives like payroll_remittance_schedule. Sibling tools are not referenced, leaving the agent to infer applicability.
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 burden. It uses non-mutating verbs ('Find', 'browse') implying a read-only operation, but does not explicitly state read-only behavior, return format, or side effects. For a simple lookup, this is adequate but not rich.
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 two short sentences with no filler. It front-loads the primary purpose and immediately conveys how to interact with the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has low complexity (one optional parameter, no output schema), but the description does not specify what the lookup returns (e.g., class number, description, tax rate). This is a minor gap given the simple nature of the tool, so it is minimally complete.
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?
The sole parameter (search_term) is fully documented in the schema with a clear description and example. The description adds modest context by mentioning 'search by asset type' but does not surpass the schema coverage. Baseline of 3 is appropriate since schema_description_coverage is 100%.
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 a specific verb ('Find') plus resource ('correct CCA class for a capital asset') and distinguishes from sibling tools like calculate_cca by focusing on classification lookup. It also indicates two modes: searching by asset type or browsing all classes.
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 by describing what the tool does, but it does not explicitly contrast with sibling tools such as calculate_cca. It provides no when/what-not-to-use guidance, so the agent must infer context from the tool name.
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 burden. 'Analyze' clearly implies a read-only, non-destructive computation, and the coverage list outlines the scope of the analysis. However, it does not disclose what the output will be (e.g., a recommendation, report, or score), nor any limitations or assumptions, leaving some behavioral ambiguity.
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 two sentences, front-loaded with the primary purpose, followed by a compact list of coverage areas. Every word contributes directly to understanding the tool's function, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no annotations, the description gives the core purpose but omits what the user will receive (e.g., an analysis report, a recommendation, or a yes/no outcome) and any prerequisites. It is adequate for a simple analysis tool but lacks the behavioral and output context needed for full completeness given the parameter richness and lack of structured output documentation.
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?
The schema already provides 100% coverage with descriptive parameter definitions, so the baseline is 3. The description's coverage areas (creditor protection, surplus extraction, etc.) loosely map to parameters but do not add syntax-level or format-level meaning beyond the schema. It offers thematic context but no significant 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?
The description uses a specific verb ('Analyze whether... would benefit') with a clear resource ('holding company (Holdco) structure'). It lists distinct coverage areas (creditor protection, tax-deferred surplus extraction, passive income management, estate planning), which differentiates it from related sibling tools like estate_freeze_planner or entity_type_comparison.
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 considering a Holdco structure and mentions relevant areas (creditor protection, tax deferral, passive income, estate planning), but it provides no explicit 'use this when' or alternative guidance. There is no exclusion or differentiation from sibling tools, so it stops at implied usage rather than clear direction.
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 of behavioral disclosure. It mentions the tests and status checked, which gives some insight into behavior, but it does not state that the tool is read-only, how it handles ambiguous inputs, or what the result type is (e.g., boolean or detailed report). This is a gap given 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and specific test names. Every sentence provides useful information without redundancy, achieving high conciseness and clear structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a nuanced tax qualification check with 8 parameters and no output schema, so the description should ideally explain what the tool returns and how the tests are applied. It names the tests but does not explain their thresholds or the output format, leaving the user to infer results. This is a moderate gap for a complex 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 description coverage is 100%, so the schema already documents all 8 parameters with meaningful descriptions. The tool description does not add parameter-specific semantics beyond the schema, so the baseline of 3 applies. It names the tests but does not map them to specific 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 tool determines if corporation shares qualify for the Lifetime Capital Gains Exemption, specifying the exact exemption amount and naming the tests it checks (90% test, 50%/24-month test, CCPC status). This distinguishes it from sibling tax tools like asset_vs_share_sale or holding_company_analysis.
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 for LCGE qualification assessment but provides no explicit when-to-use or when-not-to-use guidance, and does not mention alternatives among the sibling tools. It is clear enough for a user looking for LCGE qualification, but lacks explicit exclusions or comparisons.
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 provided, the description must disclose behavioral traits, but it only says 'Add or toggle,' implying mutation without explaining consequences, permissions, reversibility, or how the rule is applied to tax calculations. It lacks critical safety and side-effect information expected for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded, and every sentence earns its place. It quickly states the core function, defines the domain, and provides two illustrative examples without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a solid definition and examples, but the tool has 8 parameters and no output schema or annotations. It lacks details on the rule lifecycle (e.g., updating or deleting rules), how 'toggle' maps to enable/disable, and what happens after a rule is added. This is adequate but leaves notable gaps.
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%, so each parameter has a description in the schema. The tool description adds examples of custom rules but does not elaborate on the specific parameters or their relationships, relying on the schema's minimal definitions. It meets the baseline but adds little extra meaning.
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 function with a specific verb and resource: 'Add or toggle a custom tax rule.' It explains what custom rules are and provides examples, distinguishing it from standard-knowledge tools and calculation tools among the siblings.
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 gives clear context for when to use the tool: for interpretations, special scenarios, or business-specific policies not in the standard knowledge base. Examples illustrate applicability, though it doesn't explicitly name alternative tools or state 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool will 'categorize it, calculate GST, and file it properly,' which are important behavioral side effects beyond simple recording. It also mentions that it will 'figure out if it's income or expense from the description,' providing insight into the tool's auto-detection behavior. The description does not disclose potential mutations or reversibility, but for a creation tool this is acceptable and useful context.
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 three sentences long, front-loaded with the core purpose, then instructions, then outcomes. Every sentence earns its place: the first defines the action, the second explains required inputs, and the third describes follow-up behavior and the tool's role. There is no fluff or repetition, making it appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters and no output schema, the description covers the main workflow and user-facing instructions, but it omits details about what the response will look like (e.g., confirmation, transaction ID) and any prerequisites (e.g., business setup). It also does not mention optional parameters like receipt_path or has_receipt, but these are fully described in the schema. The description is complete enough for a simple record action but lacks some agent-facing operational context.
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 some meaning by grouping parameters ('what you bought/earned, from whom, how much, and when') and noting that the tool will auto-determine income vs. expense from the description, which complements the is_revenue parameter. However, it adds no detail about formats or constraints beyond what the schema already provides, and it does not clarify the relationship between is_revenue and the auto-detection claim.
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 records a business expense or income, using the specific verb 'Record' and the resource 'business expense or income'. It includes a direct call to action: 'Tell me what you bought/earned, from whom, how much, and when.' While it doesn't explicitly distinguish from siblings like record_bulk_transactions, the phrase 'This is how you feed me your receipts and invoices' positions it as a primary method for individual transactions, making the purpose clear.
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 provides implicit guidance by instructing users what information to provide ('what you bought/earned, from whom, how much, and when'), which maps to key parameters. However, it does not explicitly state when to use this tool versus alternatives like record_bulk_transactions, record_receipt, or import_csv. There are no exclusions or named alternatives, so an agent might not know which tool is best for multi-transaction uploads or receipt-specific workflows.
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 provided, the description must fully disclose behavioral traits. It does mention persistence ('I'll remember everything for future sessions'), which is useful, but it fails to disclose critical side effects for a write operation: whether calling it twice overwrites data, whether it is idempotent, or any error conditions. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core action ('Set up the business profile'), and every clause adds meaning—establishing the tool's role, the context of being first, and the persistence promise. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, required fields) and no output schema, the description provides enough to understand the basic intent but omits important operational details: what happens if the profile already exists, how to update it later, or what the response format is. The full parameter descriptions in the schema help, but the description's vagueness about lifecycle and data handling leaves gaps.
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?
The schema covers 100% of parameters with individual descriptions, so the baseline is 3. The description adds no additional parameter-level detail beyond saying 'tell me about your business,' which is too generic to enhance the schema. Thus, it meets the baseline but does not exceed it.
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 purpose with a specific verb and resource: 'Set up the business profile.' It also distinguishes itself from siblings like update_profile by explicitly positioning it as 'the first step' in onboarding a business, and it clarifies the overarching role ('your in-house tax accountant'), making the intent unmistakable.
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 phrase 'This is the first step' provides a clear contextual signal for when to use the tool (at the beginning of a client relationship). However, it does not explicitly mention exclusions or alternatives (e.g., 'use update_profile for later changes'), so it falls short of the highest tier but still offers more than just vague implication.
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 carries the full transparency burden. It tells what it does (shows deadlines) and mentions 'filing and payment' types, but does not disclose edge-case behavior such as empty results, whether the window is relative to today, or any side effects. It is adequate but not rich.
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 two concise sentences that front-load the primary purpose and then add the window detail. There is no fluff or redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description leaves ambiguity about what 'upcoming' means (from today vs. from fiscal year-end) and does not describe the return format. It is adequate for a simple tool but has clear gaps that could force an agent to guess.
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?
The schema already provides 100% coverage with clear descriptions for both parameters (fiscal_year_end and days_ahead). The description's references to 'fiscal year-end' and 'specified window' add no new information beyond what the schema documents, so it stays at the baseline of 3.
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 'Show' and the resource 'upcoming tax filing and payment deadlines', with the basis 'fiscal year-end' and 'specified window'. It is specific and self-contained, though it does not explicitly distinguish itself from a sibling like 'filing_calendar'.
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 provides clear context: use when you want upcoming tax deadlines within a specified window based on fiscal year-end. However, it does not mention exclusions or alternative tools, so it stops short of explicit when/when-not guidance.
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?
No annotations are provided, so the description carries the full burden of explaining behavior. It does not disclose whether updates overwrite existing values, if any validation occurs, whether changes are reversible, or what the return response looks like. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences long and front-loads the core action ('Update a field on the business profile') before giving usage context. Every word earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with full schema coverage, the description is adequate but not rich. It omits behavioral details such as error behavior, permission requirements, or confirmation, and there is no output schema to fill in return-value expectations. Still, the basic update purpose is clear enough for minimal use.
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?
The schema covers both parameters fully (100% coverage) with an enum for 'field' and a type description for 'value.' The description adds example fields in prose but does not add semantic meaning beyond the schema, so the baseline 3 applies.
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 opens with 'Update a field on the business profile,' which is a specific verb+resource phrasing that clearly states the tool's function. It distinguishes this tool from siblings like view_profile (read-only) and setup_business (initial setup) by focusing on updating an existing profile.
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 'Use this when you get new information like your Business Number, GST registration, or payroll details,' providing clear usage context. However, it does not mention when not to use it or name alternative tools, so it stops short of full explicit guidance.
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 itself must convey behavior. It clearly indicates a calculation (read-only) operation and identifies the two relevant clawback factors, but it does not disclose assumptions, edge cases, or what the returned value represents beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the verb, resource, and key factors with no filler or redundant information.
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 straightforward calculator with three well-documented parameters and no output schema, the description adequately covers the tool's purpose and primary inputs. It could be more complete by explicitly stating the return value (the calculated limit amount), but that is largely inferable from the title and description.
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?
The input schema covers all parameters at 100%, including descriptions for passive_income, taxable_capital, and associated_group_limit. The description adds contextual meaning by linking the parameters to clawbacks, but does not add new details 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 names the specific resource (the adjusted Small Business Deduction business limit) and the calculation inputs (taxable capital and passive income clawbacks). This distinguishes it from broader corporate tax or instalment calculators among the siblings.
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 when to use the tool (when calculating the SBD limit after clawbacks) but provides no explicit when-not-to-use or alternate tool references. It does not mention prerequisites like associated group capital, leaving some room for interpretation.
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 provided, the description must disclose behavioral traits, but it only states what the tool assesses without explaining effects, prerequisites, or output. There is no mention of whether the tool is read-only, requires additional data, or how results are presented. This leaves significant gaps for the agent.
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 two short sentences, front-loaded with the core action and resource, then quickly listing coverage. Every word earns its place with no unnecessary detail.
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 complexity of 7 parameters and no output schema, the description provides enough context to understand the tool's domain and scope. It names the legal sections and key coverage areas, which is sufficient for a specialized assessment tool, though it could benefit from stating the type of output (e.g., a liability estimate).
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?
The input schema provides 100% parameter descriptions, so the baseline is 3. The description adds minimal context by relating parameters to legal sections (e.g., 'unremitted source deductions' maps to unremitted_source_deductions), but it does not meaningfully enhance understanding 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's purpose: 'Assess personal liability exposure for corporate directors' with specific legal references (Section 227.1 ITA, Section 323 ETA). It distinguishes itself from sibling tools by focusing on director liability, a unique area not covered by other tools like calculate_corporate_tax or audit_risk_assessment.
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 provides clear context for when to use the tool by naming the specific liabilities covered (unremitted source deductions, GST, due diligence defence). It does not explicitly state when not to use it or name alternatives, but the scope is specific enough to guide selection among the many sibling tools.
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 must carry the full behavioral burden. It transparently signals a non-destructive determination by saying 'Determine if' and mentions that restrictions are provided, which adds value. However, it does not disclose how inputs like business_use_percent or annual_taxable_supplies factor into the decision or describe the 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the purpose and output without waste. Every word earns its place.
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 plus fully documented schema covers tool selection and input invocation. Return format is not formally specified, but the phrase 'Determine if... and any restrictions' gives a functional idea of the output. Without an output schema, it could benefit from a note about result structure, but it's sufficiently complete for an eligibility check.
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 each of the four parameters is already documented clearly. The description does not add parameter-level detail beyond the schema, which is acceptable per the baseline; it doesn't conflict or leave undocumented 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 uses a specific verb ('Determine if') and clearly identifies the resource ('a purchase qualifies for an Input Tax Credit (ITC)') and output scope ('any restrictions that apply'). This distinguishes it from sibling GST tools like calculate_gst or gst_quick_method_analysis, which focus on calculating amounts rather than eligibility determination.
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 phrase 'Determine if a purchase qualifies' implies the tool should be used when checking ITC eligibility for a purchase, providing a clear context. However, it does not provide explicit when-not-to-use guidance or name alternatives such as calculate_gst, so usage boundaries are only implied.
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 must carry the full burden. The verb 'Display' implies a read-only operation, but no additional behavioral context is given (e.g., data source, update frequency, or limitations). This is adequate but has clear gaps.
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, concise sentence that directly states the tool's function without any filler. It is appropriately sized and 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 parameterless reference tool with no output schema, the description fully specifies the data returned. It clearly communicates the scope of the rates, making it complete enough for an agent to invoke 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 zero parameters, so the baseline is 4. The description adds scope by specifying which rates are shown (federal, Alberta, small business, general), but no parameter-related semantics are needed.
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 displays current federal and Alberta corporate tax rates, including combined rates for small business and general income. The verb 'Display' and specific resource differentiate it from calculation-focused siblings like calculate_corporate_tax.
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 is provided on when to use this tool versus alternatives such as get_effective_rates or calculate_corporate_tax. The description only states what the tool does, not the context for selecting it.
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 carries the full burden. It discloses that the tool covers two specific tax methods, which adds behavioral context. However, it does not describe the nature of the output (e.g., a report, calculations), whether it reads or modifies data, or any side effects. This is a moderate level of transparency for a planning 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 two concise sentences that immediately state the purpose and key coverage. Every word earns its place; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters and no output schema, so the description should explain what the tool produces or how the plan is delivered. It does not specify the output format or execution behavior, leaving some ambiguity. However, it does set clear expectations about the purpose and methods, which is adequate but not complete.
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?
The input schema covers all 6 parameters with clear descriptions and defaults, achieving 100% schema_description_coverage. The tool description adds no parameter-specific information, but the schema already documents semantics thoroughly, so the baseline of 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 a specific action ('Plan an estate freeze') with a defined objective ('lock the current owner's value and shift future growth to the next generation'). It further distinguishes from siblings by naming the specific methods (Section 86 and Section 85), making it unique among related tools like reorganization_advisor or asset_vs_share_sale.
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 clear context for when to use it: when planning an estate freeze. The mention of Section 86 and 85 rollovers gives a sense of the method scope. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a full 5.
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 carries the full burden for behavioral disclosure. It indicates the tool is a calculator (implying read-only), and it adds useful context about income types and the legal section. However, it does not describe limitations, edge cases, or the exact nature of the returned result, which leaves some ambiguity for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 ('Calculate') and the specific object ('available foreign tax credit under Section 126'). It contains no redundant information and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, so the description must carry more weight. It adequately identifies the purpose and income types, but it omits details about calculation limits (e.g., the credit being the lesser of foreign tax paid and Canadian tax on foreign income) and the return format. For a tool with six required parameters, this leaves some gaps in 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?
The schema already provides 100% coverage for all six parameters, so the description adds only marginal value by clarifying the business/non-business distinction and referencing Section 126. It does not explain parameter relationships or calculation logic beyond what the schema already states.
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 primary function: calculating the available foreign tax credit under Section 126. It distinguishes between business and non-business income, which directly matches the income_type parameter and helps differentiate this tool from siblings like corporate tax calculators or treaty rate lookups.
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 clearly implies when to use the tool—when calculating foreign tax credits for Canadian tax purposes on foreign income. It provides clear context (business vs. non-business income) but does not explicitly mention alternatives or when not to use it, leaving a slight gap in exclusion guidance.
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 carries the full burden of behavioral disclosure. It does state a key side effect: 'then record it as a transaction.' It also discloses what data it extracts (vendor, date, amounts, line items, GST). However, it does not mention failure modes, idempotency, required permissions, or any reversibility of the transaction recording.
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 three sentences long and every sentence adds value: the first identifies the action, the second lists the extracted data, and the third clarifies compatible document types. It is front-loaded with the primary purpose and contains no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should help the agent understand what happens after invoking it. It states that it 'record[s] it as a transaction,' but does not explain the return value or what confirms success. Given the tool's moderate complexity (nested extracted_data object, 3 params) and rich schema coverage, the description is adequate but leaves some gaps about the operation's outcome.
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%, so the baseline is 3. The description mentions fields like 'vendor, date, amounts, line items, and GST' that map to extracted_data fields, but the schema already describes these in detail. The description does not add meaningful syntactic or semantic detail beyond the schema, nor does it clarify the required 'file_path' or the optional 'document_type' beyond what the enum already indicates.
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 function: 'Read a PDF invoice or receipt and extract the transaction data' and then 'record it as a transaction.' It specifically names PDFs, distinguishing it from sibling tools like import_csv and import_spreadsheet, and enumerates document types (invoices, receipts, statements, bills).
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 gives clear context for when to use this tool: when you have a PDF document. It does not explicitly state exclusions or alternatives, such as 'use import_csv for CSV files,' but the mention of 'PDF invoice or receipt' and the list of document types implies the appropriate use cases. There is no explicit '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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of disclosing behavior. It mentions 'I'll do the rest', suggesting automatic handling, but does not disclose side effects, data validation, error handling, or what happens after import. This is a significant gap for a write operation.
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 and front-loaded with the core action, followed by a clear explanation of the mapping feature. The final sentence adds contextual flavor without unnecessary verbosity. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested parameter schema and no output schema. While the schema is detailed, the description does not mention return values, error conditions, or post-import behavior. Given the complexity of column mapping, the description is adequate but not fully 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?
The schema provides 100% coverage of parameter descriptions, giving a baseline of 3. The description adds value by explaining the high-level intent of column mapping ('tell me which columns hold the date, description, amount, category') and implying that the tool handles optional fields automatically, which goes beyond what the schema explains.
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 action ('Import'), the resource ('your own expense tracking spreadsheet'), and the format ('CSV format'). It also mentions the flexible column mapping feature, which distinguishes it from other import tools in the sibling list like import_pdf.
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 provides clear context for when to use this tool (when you have a CSV expense spreadsheet, especially one with messy/non-standard columns) and emphasizes flexibility through column mapping. However, it does not explicitly mention alternatives or when not to use it, so it falls slightly short of a perfect score.
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 does disclose core behavior (calculates depreciation, supports half-year rule and Accelerated Investment Incentive), but it does not state whether the operation is read-only, what output is returned, or any assumptions about defaults beyond the schema. It offers moderate transparency, not rich detail.
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, front-loaded sentence with no filler. Every phrase adds value by specifying the calculation scope and supported rules. It is appropriately sized for the tool's purpose.
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?
With no output schema, the description and parameter schema together are mostly sufficient. The purpose and supported options are clear, and the years_to_project parameter hints at the output being a CCA schedule. Minor gaps remain, such as explicitly stating return format and assumptions, but overall completeness is good for a calculator tool.
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 semantic meaning by mapping high-level features to parameters: 'all CCA classes' relates to cca_class, 'half-year rule' relates to is_first_year, and 'Accelerated Investment Incentive' relates to use_accelerated_incentive. This goes beyond simply restating 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 a specific action ('Calculate CCA (depreciation)') on a specific resource ('a capital asset'), and adds differentiating features ('Supports all CCA classes, half-year rule, and Accelerated Investment Incentive'). This distinguishes it from sibling tools like cca_class_lookup, which is more about class rules than calculation.
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 when to use the tool (whenever CCA calculation is needed) but does not explicitly state alternatives or exclusions. It mentions supported rules, giving some context, but there is no 'use this instead of X' guidance even though sibling tools exist.
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 carries the full burden. It adds coverage context beyond the schema by naming supported methods and rates, but it does not disclose output format, assumptions, or potential limitations, leaving some behavioral ambiguity.
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 two sentences with no wasted words. The first sentence delivers the core purpose, and the second adds useful coverage details. Excellent front-loading and structure.
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 calculation tool with rich schema and no output schema, the description gives a solid understanding of scope and supported methods. It lacks explicit output format or edge case handling, but is generally sufficient for an AI agent to decide when to invoke it.
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 schema fully documents all 6 parameters. The description adds minimal parameter-specific information beyond what the schema provides, referencing proxy method and CCPC rate which map to schema properties but without new 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 clearly states the tool calculates SR&ED tax credits for federal and Alberta jurisdictions. It names a specific verb and resource, and its focus on SR&ED distinguishes it from sibling tools like calculate_corporate_tax.
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 SR&ED credit calculations and mentions specific coverage (enhanced CCPC rate, proxy method, Alberta IEG), providing clear context. However, it does not explicitly state when not to use it or contrast it with general corporate tax tools.
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 must carry the transparency burden. It conveys a read-only nature through 'See' and indicates scope ('for the fiscal year') and the dashboard's focus on money movement, but it does not disclose whether the data is live, aggregated, or dependent on setup/recorded transactions, nor does it describe response 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?
Two sentences with the key content front-loaded; every phrase adds value. It is appropriately brief for a dashboard summary tool.
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 specifies the three report sections it returns and the fiscal-year scope, which is sufficient given the simple optional-parameter schema. However, without an output schema, it does not clarify presentation format or how the sections are computed, and it omits any behavior around default values or prerequisites, making it slightly incomplete.
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?
Both parameters (quarter, fiscal_year) already have schema descriptions covering 100% of parameters, so the baseline is 3. The tool description adds no additional semantic detail; it only repeats the fiscal-year scoping already present in 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 a specific viewing verb ('See') and lists concrete resources (income statement, balance overview, GST position), clearly distinguishing this dashboard from transaction-recording and calculation siblings. The phrase 'bookkeeping dashboard' reinforces its role as an aggregating overview.
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 identifies this as the 'bookkeeping dashboard' and frames it as the place to see where money is going, giving clear context for when to use it. However, it does not mention any alternative tools or exclusions, such as when to prefer detailed reports like chart_of_accounts or tax calculations.
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 burden of behavioral disclosure. It states the tool compares methods and shows savings, and includes an eligibility threshold. However, it doesn't disclose assumptions (e.g., how is_reseller affects the calculation) or the exact nature of the output, which would be valuable.
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 two sentences, front-loaded with the primary purpose and followed by the eligibility constraint. Every sentence earns its place, with no redundant or filler content.
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?
With no output schema and no annotations, the description covers purpose, eligibility, and expected result. It doesn't explain how the optional is_reseller parameter factors into the analysis, but for a calculator tool, this is a minor gap. Overall the description is reasonably complete.
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?
The input schema provides 100% description coverage for all three parameters, with clear definitions. The tool description adds eligibility context but no additional parameter semantics beyond what the schema already provides, so the 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 uses a specific verb ('Compare') and names the resource ('Quick Method of accounting vs. regular GST method'), and states the outcome ('Shows potential savings'). This clearly distinguishes it from sibling tools such as calculate_gst or gst_registration_assessment.
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 gives a clear eligibility condition: 'Available for businesses with annual taxable supplies up to $400,000.' This tells the agent when the tool is applicable, but it doesn't explicitly name alternatives or state when not to use it, hence the slight deduction.
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 takes on the full burden. It discloses that the tool compiles data from transactions and shows what to report, which is useful. However, it does not explicitly state the tool's read-only nature, required setup, or any side effects, leaving some room for inference.
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 two sentences long, front-loads the primary action ('Compile...'), and adds the key outcome ('Shows exactly what to report'). Every word is purposeful with no repetition or fluff.
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 simplicity (one parameter, no output schema, no nested objects), the description adequately covers purpose, process, and result. It explains what the resulting worksheet contains conceptually. It doesn't address edge cases or prerequisites, but for this scope, it is sufficiently complete.
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?
The only parameter, 'period', is fully described in the schema with format examples, achieving 100% schema coverage. The tool description does not add any additional parameter-level semantics, so it meets the baseline of 3 but does not exceed it.
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 the specific verb 'Compile' and clearly identifies the resource: 'GST collected and ITCs paid from your transactions into a GST return worksheet.' It distinguishes itself from sibling tools like calculate_gst or prepare_t2_worksheet by focusing on worksheet preparation and reporting.
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 conveys clear context for when to use the tool: when you need to compile transaction data into a GST return worksheet. It implies the report-ready purpose, but it does not explicitly mention alternatives or when not to use it, so it misses the top score.
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 carries the full burden. It states it 'reviews all transactions, applies tax adjustments, and calculates tax owing,' which gives insight into internal processing. However, it doesn't disclose whether the worksheet is saved, permissions needed, or any side effects, so it's not fully 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?
Three sentences, each earning its place: first states the core action, second explains the user benefit, and third describes the process. No redundancy or fluff.
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 2-parameter tool with no output schema, the description adequately explains the purpose, process, and outcome. It lacks details on the exact output format or edge cases, but is sufficient for a worksheet preparation 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?
The schema description coverage is 100%, so both parameters (fiscal_year and additional_adjustments) are already documented. The description adds context by mentioning 'applies tax adjustments' and 'bookkeeping data,' but doesn't provide new syntax or format details 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 the specific verb 'Compile' and clearly identifies the resource: 'T2 corporate income tax return worksheet' from 'bookkeeping data.' It also mentions generating numbers for CRA, which distinguishes it from siblings like prepare_gst_worksheet and calculate_corporate_tax.
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 context is clear: it's for preparing a corporate T2 worksheet from bookkeeping data for CRA filing. It doesn't explicitly state when not to use or name alternatives, but the T2 focus and mention of 'reviews all transactions' implies a comprehensive corporate tax preparation scenario.
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 present, so the description carries the full burden. It discloses that the tool will 'categorize them all', which is a behavioral trait beyond the schema. However, it does not mention potential failure modes, validation constraints, or whether records are appended or overwritten. For a bulk write operation, this is a moderate disclosure.
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 two sentences, front-loaded with the purpose, and every sentence provides value. The first sentence states the action, the second gives use cases and hints at behavior. No fluff.
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 is a bulk write with no output schema, the description is reasonably complete. It explains the core action, appropriate use cases, and the categorization behavior. It doesn't need to detail return values since no output schema exists, and the input schema is fully self-explanatory.
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?
The schema description coverage is 100%, with all properties documented including nested item fields. The description says 'Give me a list' which aligns with the 'transactions' array parameter but adds no further semantics. Since the schema already fully describes parameters, 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 states the tool records multiple transactions at once, which is a specific verb and resource. It clearly distinguishes from the sibling tool 'record_transaction' by emphasizing 'multiple at once', and from import tools by describing a direct list input rather than file-based import.
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 gives clear use cases: 'great for entering a batch of receipts or a month's worth of bank statement entries.' This provides context for when to use the tool. It doesn't explicitly contrast with alternatives like 'import_csv' or 'record_transaction', but the 'multiple at once' positioning is implicit differentiation.
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?
The description explains the state change ('mark as resolved') and its trigger, but with no annotations available, it does not disclose potential side effects, reversibility, or permission requirements. However, the tool is simple enough that the core behavior is 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, front-loaded sentence that conveys the action and condition with no redundancy.
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 low complexity (one parameter, no output schema), the description covers the core purpose and usage condition, though it omits what the tool returns upon success.
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?
The input schema already describes the only parameter (insight_id) with 100% coverage, and the description does not add additional semantic meaning beyond reiterating it is a task insight.
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 action ('Mark...as resolved') and the resource ('task insight'), distinguishing it from sibling tools like resolve_note. The condition for resolving is also provided.
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 provides a clear precondition for when to use the tool ('after the gap has been addressed or the improvement has been implemented'), but does not explicitly mention 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden. It reveals that the tool filters out already-processed images, which is useful, but it doesn't explain how processing state is tracked, what file formats are supported, or the exact return 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?
Two sentences with no fluff; the first states the core action and the second adds context and a downstream call. Every word earns its place.
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 single-parameter read-only list tool, the description is largely complete, but the lack of return format details and processing-state semantics leaves minor gaps.
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?
The schema already describes folder_path fully (100% coverage). The description adds no extra parameter semantics, so the baseline of 3 applies.
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 the specific verb 'List' with the resource 'receipt images in a folder' and the scope 'that haven't been processed yet', clearly distinguishing it from sibling tools like missing_receipts or import 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?
The description provides a concrete use case ('when you dump a bunch of receipt photos into a folder') and explicitly links to the next step (call record_receipt), but does not mention alternative tools 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It mentions the output (a tailored list) but does not explain whether it reads user profile data, has side effects, or any limitations. This is a significant gap for an unannotated 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?
Two concise sentences front-load the core purpose and immediately differentiate the tool from generic advice. Every word earns its place with no unnecessary detail.
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 zero-parameter, no-output-schema tool, the description adequately covers the main function and output. The only minor gap is not clarifying how 'your specific business' is determined (e.g., from an existing profile), but this is a simple informational tool, so the description is largely 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?
The tool has zero parameters, so there are no input semantics to explain. The description does not need to compensate for schema gaps, and the baseline of 4 applies.
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 provides a tailored list of required records/documents based on the user's business. It distinguishes itself from generic resources by explicitly saying 'No generic advice', which sets it apart from sibling tools like record_keeping_guide.
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 when a user needs personalized record-keeping requirements, and the phrase 'No generic advice' signals a differentiation from generic guides. However, it does not explicitly name alternative tools or provide formal when-not-to-use 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It accurately conveys that the tool is an assessment that computes a risk score and provides recommendations, implying a read-only analytical operation with no side effects. It does not explicitly state that no data is stored or modified, but the nature of the tool makes this clear enough.
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 two sentences that front-load the core purpose and output. Every word contributes value: it states the resource, the criteria, and the deliverables. No unnecessary details or repetition.
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 is sufficient for a tool with no output schema, as it explicitly says the result includes a risk score and mitigation recommendations. While it could add caveats about the assessment being an estimate or based on heuristics, the core function and output are clearly covered. Given the tool's complexity (12 params), the high schema coverage compensates for the lack of parameter detail in the description.
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?
The input schema includes descriptions for all 12 parameters (100% coverage), so the description does not need to explain them. The description's reference to 'common triggers and red flags' is generic and adds no specific parameter-level meaning beyond the schema. Baseline 3 is appropriate given the high schema coverage.
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 function: 'Assess your business's risk of being selected for a CRA audit based on common triggers and red flags.' It specifies the resource (CRA audit risk) and the action (assess), and it mentions the output (risk score and mitigation recommendations). This distinguishes it from siblings like tax_health_check or missing_receipts, which focus on 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 provides clear context for when to use the tool: when a business wants to evaluate its likelihood of a CRA audit based on red flags. It does not explicitly mention alternatives or exclusions, but the highly specific purpose makes appropriate usage obvious. The absence of alternative pointers is a minor gap, not a failure.
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 carries the full burden. It goes beyond a simple 'show' statement by disclosing that it includes overrides and highlights updated vs. default values, which is valuable behavioral context for an agent.
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, consisting of three short sentences that each add value. It front-loads the main verb and purpose, with no filler or redundancy.
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 covers the core purpose, behavioral nuance, and use case. It does not describe return format, but that is less critical given the tool's simplicity.
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?
The schema already provides full coverage of the single 'category' parameter with a clear description and enum. The tool description does not add extra parameter-specific semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 function: 'Show the currently effective tax rates' and distinguishes it from sibling tools by emphasizing overrides from the learning system. The verb 'show' and resource 'effective tax rates' make it specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit use case: 'Use this to verify what rates the agent is actually using for calculations.' This provides clear context for when to use the tool, though it does not mention alternatives or 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?
With no annotations, the description carries the burden of transparency. It explicitly discloses the optional side effect of creating a knowledge override, which is the most important non-obvious behavior. It could add detail about persistence or response, but it covers the key trait.
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 front-load the purpose and usage trigger, with no wasted words. Every clause adds value.
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?
Despite having 8 parameters and no output schema, the description adequately conveys purpose, side effects, and when to use the tool. It could mention return/confirmation behavior but is complete enough for a logging 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 description coverage is 100%, and the description does not add parameter-level semantics beyond what the schema already provides. This matches 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 and resource ('Record when a calculation, rate, or rule was found to be incorrect') and clearly distinguishes this tool from siblings like log_research or update_knowledge by focusing on corrections and optional knowledge overrides.
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 provides a clear usage trigger ('Use this whenever you find a mistake in the agent's output or when a user points out an error'), but does not name alternatives or when-not-to-use scenarios, stopping short of a 5.
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 provided, the description carries the full burden. It discloses the primary behavioral outcome: 'Builds a searchable knowledge base of everything the agent has researched,' indicating the persistent, cumulative nature of the log. It does not discuss edge cases like overwriting or editing, but for a record-keeping tool, the stated behavior 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?
The description is exactly four sentences, each earning its place: the primary action, the trigger condition, the outcome, and concrete examples. It is front-loaded with the purpose and contains zero filler.
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 covers purpose, usage, outcome, and examples, which is sufficient for a logging tool with 100% schema coverage. It does not mention return values or error handling, but that is acceptable since the tool's primary function is to record data, not to return complex results.
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 itself does not add parameter-level meaning, but the schema already documents each parameter thoroughly (e.g., 'What was learned', 'Brief topic name'), so no compensation is needed.
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 opens with a specific verb 'Record' and resource 'findings from tax research,' immediately distinguishing this from calculation tools. It also provides three concrete examples (SR&ED eligibility, treaty rates, CCA class) that clearly scope the tool as a research-logging tool among many calculation and knowledge-management siblings.
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 sentence 'Use this whenever you investigate a tax topic, look up a rule, or explore how something works' explicitly states when to use the tool. It does not mention when not to use it or name alternatives, but the trigger condition is clear and differentiates it from calculation-oriented siblings.
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 carries full burden. It discloses the workflow (Claude reads the image, user provides details, transaction created with proof), which is valuable behavioral context. It does not mention side effects or error cases, but the core mutation and proof-linking behavior are clear.
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 two sentences, front-loaded with the essential action, and includes a key use case in the last sentence. No wasted words, highly scannable.
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 11 parameters, 4 required, and no output schema, the description provides enough context for the core workflow. It clarifies the role of the image and proof, but leaves detailed param nuances to the schema. The tool is well-scoped and the description is sufficient for an agent to understand its role.
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?
The schema has 100% parameter description coverage, so the baseline is 3. The tool description itself does not add parameter-level details beyond the schema, but it does mention 'you provide the extracted details' as a workflow hint. This is sufficient but not exceptional.
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 states a specific action ('Record a transaction from a receipt photo'), identifies the resource (receipt photo), and clarifies the output (transaction with image linked as proof). It distinguishes itself from sibling tools like record_transaction and scan_receipts_folder by focusing on photo digitization.
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 when to use the tool ('This is how you digitize paper receipts') and contrasts with broader record tools. It clearly covers the single-receipt photo scenario but does not explicitly state alternatives or exclusions (e.g., when to use record_transaction instead).
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 clearly frames the operation as observational ('See everything') and lists the kinds of stored learning content, including 'unresolved gaps' and 'usage stats', which gives the agent a good sense of what to expect. It does not explicitly say 'read-only' but the verb is unambiguous and no mutating behavior is implied.
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 two sentences, front-loaded with the main purpose, and every word earns its place. It packs a clear value proposition and a use-case hint without redundancy or fluff.
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 simplicity (two optional params, no output schema, no nested objects), the description adequately conveys what the tool returns and why it matters. It could mention that results are filterable via section_filter or that the default view is an overview, but those details are already present in the input schema, so the description is complete enough for tool selection.
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%, so the baseline is 3. The description's list of categories roughly maps to the section_filter enum values but adds little beyond what the enum and property descriptions already state. It does not explain the 'search' parameter beyond the schema, so it only marginally enhances parameter understanding.
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 the specific verb 'See' and identifies the resource as 'everything the agent has learned', then enumerates distinct content categories (knowledge updates, research findings, corrections, unresolved gaps, custom rules, usage stats). This clearly distinguishes it from sibling writing tools like update_knowledge and log_research.
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 provides clear context for when to use the tool: 'Use this to understand how the agent has evolved and what still needs attention.' It does not explicitly state when not to use it or name alternative tools, but the read-only nature relative to sibling logging/update tools is implied.
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 carries the full burden. It transparently discloses key calculation factors (CPP/EI, RRSP room, integration imperfections) but does not mention output format, assumptions, limitations, or side effects. This is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary verb 'Compare' and delivers essential information without redundancy. Every phrase adds value.
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 calculator with 4 parameters and no output schema, the description covers the core purpose and factors. It does not specify the exact return format or any prerequisites, but given the moderate complexity and full schema descriptions, it is mostly complete. A small gap remains around output 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%, giving a baseline of 3. The description adds meaning by linking parameters to functional purpose: 'RRSP room' relates to needs_rrsp_room and 'CPP/EI' to needs_cpp_benefits, and it explains the overall objective of the calculation. This goes 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's function: comparing total tax cost among salary, eligible dividends, and non-eligible dividends. It uses specific verbs and a clear resource, and it distinguishes itself from sibling tools like calculate_payroll or calculate_corporate_tax by explicitly focusing on extraction method comparison.
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 context clearly: when deciding how to extract corporate income as salary vs dividends. However, it does not explicitly mention when not to use it or provide alternative tool names, so it lacks explicit exclusions/alternatives but still offers a 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?
With no annotations, the description discloses that the tool builds usage analytics and is typically invoked automatically, adding behavioral context beyond the schema. However, it does not detail potential side effects like persistence or response behavior.
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 two sentences, concise and front-loaded with the primary action. Every sentence contributes either the tool's function or its typical usage pattern, with no redundant information.
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 low-complexity tracking tool with well-documented parameters and no output schema, this description sufficiently covers purpose and invocation context. It could mention whether manual use has any caveats, but it is otherwise complete for its simplicity.
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?
The schema already provides full descriptions for both parameters (100% coverage). The description's 'specific scenario' loosely aligns with input_pattern but does not add meaningful new semantics beyond what the schema already states.
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 records tool usage for a specific scenario and builds usage analytics. The verb 'Record' and resource 'tool usage' are specific, and the tool's meta purpose distinguishes it from all domain-specific siblings.
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 provides clear context: it is typically called automatically but can be used manually. This gives the agent guidance on when it might be invoked, though it does not explicitly mention exclusions or alternative tools.
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 carries the burden of behavioral disclosure. It reveals a key trait: the update is stored as an override and the original hardcoded value is preserved as a fallback. This goes beyond the schema and helps the agent understand the tool's non-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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences plus examples; no fluff. The content is front-loaded with the action and usage trigger, then the override behavior, then concrete examples. Every sentence earns its place.
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 9-parameter schema with 100% coverage and no output schema, the description covers purpose, usage, and a critical behavioral trait. It is complete enough for an agent to select and call the tool, though it doesn't describe return values (no output schema obligates that).
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 provides illustrative examples but does not add much parameter-level meaning beyond the schema's already detailed descriptions. It doesn't harm and slightly helps, but meets baseline.
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?
Description uses a specific verb ('Update') and resource ('tax knowledge entry'), and clearly distinguishes itself from siblings by scoping to knowledge changes. It lists concrete examples ('GST rate', 'SBD limit') that further clarify the tool's purpose.
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?
States explicit use cases: 'when you discover that a rate has changed, a new rule applies, or the current knowledge is outdated.' This gives clear context, though it doesn't mention when not to use the tool or name alternative sibling tools, so it doesn't earn a 5.
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?
Despite no annotations, the description discloses key behaviors: auto-detection of columns, transaction categorization, GST calculation, and supported bank formats. It doesn't mention side effects like duplicate handling or result output, but it goes beyond a minimal description.
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?
Three sentences, front-loaded with what the tool does, followed by value-add behaviors and supported formats. Every sentence contributes meaning with no fluff.
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 7-param tool with no output schema, the description explains the import process well, including auto-detection, categorization, and GST. However, it doesn't describe return values, error handling, or whether imported transactions are permanently added. This is a minor gap given the rich description.
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 has 100% coverage, so baseline is 3. The description adds meaning by explaining auto-detection (relevant to column override params) and GST handling (relevant to default_gst_included). This provides context not fully captured by 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 imports transactions from a CSV file, with specific use cases (bank statement, credit card, expense spreadsheet). It also supports multiple bank formats, distinguishing it from siblings like import_pdf and record_transaction.
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?
Clear context for when to use: CSV files from bank statements, credit card statements, or expense spreadsheets. No explicit exclusions or alternative tool names, but the use cases are well-defined and imply the appropriate scenario.
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 indicate the tool's behavior. Words like 'Show' and 'See' convey a non-destructive read operation, and it adds context about returning both current profile data and missing items. This is sufficient for a zero-parameter view tool, though it does not explicitly state side-effect safety.
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 each provide distinct value: the first states exactly what the tool does, and the second clarifies the output value. There is no redundant wording or filler.
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 zero-parameter read tool, the description covers the key aspects: what it shows (profile and setup status) and what users gain (knowing what's missing). It does not enumerate all possible profile fields, but that is not necessary for selection or invocation with no inputs. Overall, it is complete enough for this tool's complexity.
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 zero parameters, and the description adds no parameter-specific details (none are needed). The baseline for zero-parameter tools is 4, and the description adequately focuses on the tool's purpose without needing to compensate for schema 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 uses a specific verb ('Show') with a clear resource ('current business profile and setup status'). It distinguishes itself from siblings like setup_business and update_profile by focusing on viewing rather than modifying.
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 when to use the tool: to check what is known about the business and what is missing. While it does not explicitly mention alternatives or exclusions, the context of 'setup status' and 'what's still missing' clearly positions it as a discovery/read tool before performing setup or updates.
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:

[![alberta-tax-agent MCP server](https://glama.ai/mcp/servers/chiKeka/alberta-tax-agent/badges/card.svg)](https://glama.ai/mcp/servers/chiKeka/alberta-tax-agent)

Score Badge

Copy to your README.md:

[![alberta-tax-agent MCP server](https://glama.ai/mcp/servers/chiKeka/alberta-tax-agent/badges/score.svg)](https://glama.ai/mcp/servers/chiKeka/alberta-tax-agent)

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/chiKeka/alberta-tax-agent'

If you have feedback or need assistance with the MCP directory API, please join our Discord server