Canadian contractor forms + tax tools: 126 cited forms, sourced 2026 tax estimates by province.
Estimate 2026 income tax, CPP, and take-home for a self-employed Canadian contractor or tradesperson (sole proprietor) by province. Uses sourced CRA and provincial rates from tradestaxcalculator.ca. Provinces: ontario, alberta, bc, saskatchewan, manitoba, new-brunswick, nova-scotia, pei, newfoundland, yukon, nwt, nunavut (no Quebec). Planning estimate, not tax advice.
| Name | Required | Description | Default |
|---|---|---|---|
| revenue | Yes | Gross self-employment revenue for the year, CAD (before HST) | |
| expenses | No | Deductible business expenses, CAD (default 0) | |
| province | Yes | Province slug, e.g. 'ontario', 'alberta', 'bc' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It does state that it uses sourced CRA/provincial rates and is a planning estimate, which is helpful. However, it does not explain calculation assumptions (e.g., how expenses are netted against revenue, what tax credits are included, CPP exemption thresholds). For a financial calculation tool, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. The first sentence states the core purpose, followed by relevant details about data sources and supported provinces. Every sentence earns its place, with no redundant information; the province list is compact and necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should clarify what the response contains. It says it estimates tax, CPP, and take-home, but does not specify whether this is a breakdown, a single value, or a formatted report. Additionally, it does not mention edge cases like default expenses (though the schema covers this). The description is adequate but incomplete for a financial planning tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% parameter coverage, giving clear definitions for revenue, expenses, and province. The description adds meaningful value by listing all valid province slugs and excluding Quebec, which goes beyond the schema's 'e.g.' examples. This compensates for the lack of enums in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: estimating 2026 income tax, CPP, and take-home for self-employed Canadian contractors/sole proprietors by province. It is specific about the verb ('estimate'), the resource (tax, CPP, take-home), and the target audience, and it naturally distinguishes itself from sibling tools like hst_quick_method or required_hourly_rate by focusing on income tax estimation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for self-employed contractors/tradespeople, covers a list of provinces, and explicitly excludes Quebec. It also includes a 'planning estimate, not tax advice' disclaimer, which guides appropriate use. However, it does not explicitly name alternative tools to use instead for other scenarios (e.g., HST estimation), so it falls 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.
Get full details for one form by its id (from search_forms): description, regulatory citation, the exact fields it collects, and free print / Pass options.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Form id, e.g. 'field-level-hazard-assessment' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses the return payload (description, regulatory citation, exact fields, print/Pass options) and the ID source, making the operation's behavior reasonably clear. It omits edge cases like invalid IDs or auth, but these are not critical for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, well-structured with action first and a list of returned content. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter get tool with no output schema or annotations, the description adequately covers purpose, input source, and return content. It is complete enough for an agent to decide when to use it and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already documents the id parameter with an example. The description adds meaning by stating the id comes from search_forms and identifying the form as an actual form with fields and a regulatory citation, going beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'Get full details for one form by its id.' Explicitly lists the returned content (description, regulatory citation, exact fields, free print/Pass options) and references search_forms as the source of IDs, distinguishing it from siblings like get_form_maker_pass and search_forms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage: call this after search_forms to retrieve full details for a known form ID. It does not explicitly name alternatives or exclusions, but the 'from search_forms' hint provides a clear workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pricing and checkout links for the Blue Crane Form Maker Pass: one-time purchase that strips all Blue Crane text from printed PDFs (clean, client-ready paper) and auto-fills saved company details across all 126 forms.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It mentions 'pricing and checkout links' which implies a read-only retrieval, but it does not explicitly state that no purchase is made, nor does it describe the response format or any side effects. The product benefits are detailed, but the tool's own behavior remains somewhat implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose (pricing and checkout links) and then expands with relevant details about the pass's benefits. Every phrase adds value, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description provides sufficient context for the agent to understand the tool's role and what it returns (pricing, checkout links). It could be improved by explicitly stating the response format, but it is otherwise complete for a basic informational tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific meaning because there are none, but it does clarify the context of the tool (pricing/checkout) which helps the agent understand what to expect without needing parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: providing pricing and checkout links for the Form Maker Pass. It uses a specific resource (the pass) and distinct purpose (pricing/checkout), setting it apart from sibling tools that deal with forms themselves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a user needs pricing or purchase information for the Form Maker Pass, but it does not explicitly state when to use this over alternatives or provide any exclusion criteria. No direct comparison with sibling tools is given, making the 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.
Compare the CRA Quick Method of accounting for HST against the regular method for an Ontario contractor: what they would remit and keep under each, with the break-even. Planning estimate.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Business type for the quick-method rate (default services) | |
| revenue | Yes | Annual revenue before HST, CAD | |
| operating_itcs | No | GST/HST paid on operating expenses that the regular method would reclaim as ITCs, CAD (default 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It mentions the comparison and the break-even, but does not disclose assumptions, limitations, default handling, or whether the tool is read-only. The agent is left without information about edge cases or input constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core purpose, and every clause adds value. It avoids redundancy and is highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple calculator tool with no annotations and no output schema, the description gives the essential purpose but does not describe the return format or any caveats. It is adequate for a basic planning tool but lacks the depth needed to fully anticipate results, especially since the output schema is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for all three parameters (revenue, type, operating_itcs), so the description adds marginal value. It does note 'Ontario contractor' and 'break-even' but does not elaborate on parameter meaning beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares the CRA Quick Method against the regular method for an Ontario contractor, specifying the outputs (remit, keep, break-even). This distinguishes it from sibling tools like required_hourly_rate or estimate_contractor_tax, which address different tax calculations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrasing 'Planning estimate' implies use for planning/estimation, but there is no explicit guidance on when to use this tool versus sibling tools, nor any exclusions or prerequisites. The context is loosely implied but not clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the form categories (WSIB & incidents, site safety, vehicles & equipment, finance, subcontractors, etc.) with what each covers and how many forms it holds.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool returns categories, their coverage, and form counts, which is sufficient for a simple listing. However, it does not explicitly state whether it is read-only or if any side effects exist, though this is implicitly expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that leads with the primary action and then adds relevant details (examples, coverage, counts). Every word earns its place, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), the description fully captures everything an agent needs to know: what it lists, what information it provides, and how it differs from sibling tools. No further details are required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to elaborate on parameter usage. The baseline for 0 params is 4, and the description appropriately focuses on the output content rather than input details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies the resource ('form categories'), with examples of category types. This clearly distinguishes it from sibling tools like get_form or search_forms, which operate on individual forms rather than providing an overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool (when needing an overview of categories with counts and coverage), and the sibling names suggest alternatives for form-level operations. However, it does not explicitly state exclusions or mention when to prefer another tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Work backwards from the annual take-home a contractor wants to the hourly rate they must bill, accounting for 2026 income tax and CPP in their province plus billable time. Planning estimate.
| Name | Required | Description | Default |
|---|---|---|---|
| province | Yes | Province slug, e.g. 'ontario' | |
| weeks_per_year | No | Working weeks per year (default 48) | |
| overhead_annual | No | Annual business overhead, CAD (default 0) | |
| target_take_home | Yes | Desired annual after-tax take-home, CAD | |
| billable_hours_per_week | No | Billable hours per week (default 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses that it accounts for 2026 income tax, CPP, province, and billable time, and frames the output as a 'Planning estimate,' indicating approximation. However, it does not mention assumptions, output format, or limitations such as ignoring other deductions or using default values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the primary purpose and include a clear qualifier ('Planning estimate'). Every word earns its place, with no redundant information or extended explanations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and key inputs, but with no output schema and sparse annotations, it lacks details on return values, default behaviors (e.g., weeks_per_year default 48), or edge cases. For a 5-parameter tool, the description is adequate but leaves notable gaps in behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description in the input schema. The tool description adds limited semantic value beyond the schema by referring to 'billable time' and 'take-home,' but it does not detail parameter relationships or syntax. Baseline 3 is appropriate since the schema fully documents individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Work backwards from the annual take-home a contractor wants to the hourly rate they must bill.' This uses a specific verb ('work backwards') and resource (hourly rate), distinguishing it from the sibling 'estimate_contractor_tax' by its directionality. However, it does not explicitly name alternative tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an implied usage context with 'Planning estimate,' suggesting use for planning rather than exact tax filing. It does not explicitly state when to use this tool versus alternatives, nor does it list exclusions or prerequisites. The context is clear enough for a user to infer, but no explicit guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Blue Crane's compendium of 126 Canadian contractor forms — Ontario, Alberta and BC statutory worksheets plus Canada-wide site paperwork (safety, statutory worksheets, inspections, invoices, sign-offs, site logs) by keyword, form number, or alias (e.g. 'FLHA', 'form 1.2', 'hot work', 'toolbox talk'). Returns matching forms with citations and free fill-and-print URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 8) | |
| query | Yes | Keywords, a form number, or an alias |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that the tool returns matching forms with citations and free fill-and-print URLs, which is key behavioral context. It doesn't mention rate limits or auth, but as a read-only search tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence that front-loads the tool's purpose, lists supported form types, and gives examples. No fluff, but it's a bit long; still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately states return content (citations and fill-and-print URLs). It covers the scope of forms and search capabilities, making it complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema fully describes query and limit. Description adds value by providing concrete alias examples ('FLHA', 'form 1.2', 'hot work'), enriching the meaning of the query parameter beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it searches Blue Crane's compendium of 126 Canadian contractor forms with specific scope (Ontario, Alberta, BC, Canada-wide). Uses specific verb 'Search' and resource 'compendium of contractor forms', distinguishing from sibling tools like get_form or list_categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on what kinds of searches are supported (keyword, form number, alias) and gives examples, but does not explicitly contrast with siblings like get_form or which_form_do_i_need.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe a jobsite or paperwork situation in plain language (e.g. 'starting an $80k renovation in Ontario', 'GC is not paying my invoice', 'crew doing welding tomorrow') and get the forms that fit, with citations and free print links. Guidance only — not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| situation | Yes | The situation, in plain language |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the input style, the output (matching forms with citations and free print links), and the 'guidance only, not legal advice' caveat. It doesn't cover edge cases like no matching forms, but for a simple one-parameter tool this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence with illustrative examples and a disclaimer. Every part 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, single parameter, and no output schema, the description is complete: it covers input, output, and important caveats. The agent knows how to invoke it and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the sole 'situation' parameter at 100%, and the description enriches it with concrete examples and explicit 'plain language' instruction. This adds clear semantic meaning beyond the schema's minimal 'The situation, in plain language'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: users describe a jobsite or paperwork situation in plain language and receive forms that fit. The concrete examples and mention of citations/free print links distinguish it from sibling tools like get_form or search_forms, which are more direct retrieval/search operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description frames when to use the tool: when you have a situation in plain language and need form guidance. It provides clear context but does not explicitly contrast it with alternatives or state when not to use it, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Verified 2026 Canadian payroll math: employer total cost, employee take-home, net-to-gross. Free.
Verified Canadian self-employed tax math: SE tax, CPP, GST/HST, instalments, CRA deadlines. Free.
Money, tax & business calculators kept current with 2026 rules — plus operator insights.
Current source-cited 2026 US tax constants and calculators for AI agents; every answer cites IRS.
Add one secure layer between your agents and this server.
Most tools have distinct purposes: form searching/recommending vs. tax calculations vs. pass purchase. The two form-finding tools (search_forms, which_form_do_i_need) overlap somewhat, but their descriptions clarify keyword search vs. plain-language recommendation.
Naming is mixed: some verb_noun (get_form, list_categories, search_forms), some noun phrases (hst_quick_method, required_hourly_rate), and one sentence-style name (which_form_do_i_need). No consistent pattern across the set.
8 tools is well within the ideal 3-15 range and each tool covers a meaningful aspect of the domain: form search, detail retrieval, categorization, recommendation, and tax/hourly-rate utilities.
The tool surface covers the full workflow: discover categories, search forms, get details, get recommendations, plus financial planning tools (tax, HST, hourly rate). No obvious gaps for a forms-and-estimates server.
