Verified Canadian self-employed tax math: SE tax, CPP, GST/HST, instalments, CRA deadlines. Free.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.1/5 across 6 of 6 tools scored.
Each tool addresses a distinct aspect of Canadian self-employed tax: CPP contributions, full tax estimate, deadlines, GST registration, GST method comparison, and instalment plans. No overlap in functionality.
All names use lowercase with underscores, making them readable. However, they mix verb-noun patterns (e.g., get_tax_deadlines, estimate_self_employed_tax) with noun phrases (cpp_self_employed, instalment_plan), showing minor inconsistency from the ideal verb_noun standard.
Six tools is a well-scoped number for the domain. Each tool serves a necessary function without redundancy, covering major tax obligations for Canadian self-employed individuals.
The toolset covers core self-employed tax math: CPP, overall tax estimate, deadlines, GST registration and method comparison, and instalments. Minor gaps exist (e.g., detailed deduction calculators, T2125 support), but agents can work with the provided set.
cpp_self_employedAInspectCompute self-employed CPP contributions for a given year: base + enhanced contributions, CPP2 (second ceiling), total payable, and the tax-deduction vs tax-credit split that goes on the T1 (Schedule 8). Quebec residents pay QPP instead — use estimate_self_employed_tax with province QC for QPP.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| net_self_employment_income | Yes | Net self-employment income, CAD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It lists computed values and mentions an alternative for Quebec, but lacks details on side effects, authentication, or data persistence. Moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence plus a critical usage note about Quebec. Every part is essential; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists all outputs. It mentions T1 Schedule 8. Could add edge cases, but for two-parameter tool it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%. The description adds meaning: year is numeric and tied to CPP rates, net income is CAD. It clarifies the purpose of inputs beyond their names.
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 computes self-employed CPP contributions for a given year, listing specific outputs (base, enhanced, CPP2, total payable, tax split). It distinguishes itself from sibling tool estimate_self_employed_tax for Quebec residents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when not to use (Quebec residents should use estimate_self_employed_tax with province QC) but does not further elaborate on other usage contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_self_employed_taxAInspectEstimate a Canadian self-employed (sole proprietor) person's full tax bill: federal tax, provincial tax, CPP/QPP (incl. CPP2/QPP + QPIP for Quebec), total, after-tax income and effective rate. Fully verified provinces: ON, BC, AB, MB, SK, NS, NB, QC. Other provinces/territories return an honest federal+CPP-only partial estimate flagged supported:false.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | Tax year | |
| province | Yes | Two-letter province/territory code | |
| net_self_employment_income | Yes | Net self-employment income (after expenses), CAD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that unverified provinces yield a partial estimate flagged supported:false, and lists all tax components included. This transparently sets expectations about the tool's behavior and limitations.
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 yet informative, consisting of two well-structured sentences. The first sentence states the core functionality and outputs, and the second clarifies geographic coverage and fallback behavior. 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?
While there is no output schema, the description sufficiently explains what the tool returns: federal tax, provincial tax, CPP/QPP, total, after-tax income, effective rate, and a supported flag. This covers the key outputs for a tax estimation tool. Slightly more detail on response format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description reinforces the meaning of each parameter (year range, province codes, net income after expenses) and adds useful context beyond the schema, such as 'after expenses' and that year is limited to 2025/2026.
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 estimates a Canadian self-employed person's full tax bill, listing specific components (federal/provincial tax, CPP/QPP, etc.) and indicating verified provinces. It distinguishes from a partial estimate for unverified provinces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states which provinces are fully verified and that others return a partial estimate with a supported:false flag. This provides clear context on when to use the tool and what to expect, though it does not compare directly to sibling tools like cpp_self_employed or gst tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_tax_deadlinesAInspectUpcoming CRA tax deadlines for Canadian freelancers / self-employed individuals (filing, payment, GST/HST, RRSP, quarterly instalments), each on its CRA effective date with the weekend next-business-day rule applied. Also available as a subscribable calendar feed.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max deadlines to return (default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses the behavioral trait of applying 'the weekend next-business-day rule' to dates, which is beyond the input schema. However, it does not mention authentication, rate limits, or any side effects, but for a read-only tool these are less critical.
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 with no wasted words. It is front-loaded with the main purpose and includes an extra feature (calendar feed) without verbosity. Every sentence earns its place.
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 and lack of output schema, the description adequately covers what the tool returns (deadlines with weekend rule). However, it does not specify the response format or structure, which leaves some ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'limit', which already has a clear description. The tool description adds no additional meaning or context for this parameter, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'upcoming CRA tax deadlines' for Canadian freelancers/self-employed, specifying types (filing, payment, GST/HST, etc.). It is specific about the verb (get) and resource (deadlines), and it distinguishes from sibling tools like estimate_self_employed_tax or gst_hst_registration_check which focus on calculations or registrations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining tax deadlines but does not explicitly state when to use this tool versus siblings or provide any exclusion criteria. There is no guidance on prerequisites or context for use, only a listing of deadline categories.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gst_hst_registration_checkAInspectCheck whether a Canadian small business / freelancer must register for GST/HST under the $30,000 small-supplier tests (single-quarter test and rolling four-quarter test), with the exact mechanics of when to charge and the registration deadline. Set is_rideshare true for taxi/ride-share drivers (they must register from the first fare).
| Name | Required | Description | Default |
|---|---|---|---|
| is_rideshare | No | Taxi or commercial ride-share driver | |
| quarterly_revenues | Yes | Worldwide taxable revenue per calendar quarter, oldest first (up to 8 quarters), CAD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It explains the calculation tests and rideshare rule but does not mention the output format, side effects, or any prerequisites beyond the input parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first covers primary purpose and mechanics, second adds essential special case. 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?
The description explains the check logic well but omits what the tool returns (e.g., yes/no, deadline info). Without an output schema, it would benefit from describing the return value structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions, but the description adds value by explaining the significance of 'is_rideshare' and clarifying revenue ordering ('oldest first') and currency ('CAD'). This goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: checking GST/HST registration requirement for Canadian small businesses under the $30,000 small-supplier tests, including specific mechanics. It distinguishes from sibling tools like 'gst_quick_method_compare' by focusing on registration obligation rather than method comparison.
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 specifies when to use (registration check under small-supplier tests) and provides a key condition (rideshare drivers). It lacks explicit when-not-to-use or alternative tool suggestions, but context from sibling names implies this tool is for the initial registration decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gst_quick_method_compareAInspectCompare the GST/HST Quick Method against the regular method for a Canadian small business: eligibility (revenue ceiling + excluded professions), remittance under each method, and which one keeps more money. Annual figures.
| Name | Required | Description | Default |
|---|---|---|---|
| revenue | Yes | Annual taxable revenue BEFORE tax, CAD | |
| province | Yes | Two-letter province code of the permanent establishment (e.g. ON, BC, QC) | |
| business_type | No | Free-text business type, e.g. 'services', 'consultant', 'retail goods', 'bookkeeper' (used for the excluded-professions test; goods vs services rate) | |
| itc_eligible_expenses_incl_tax | No | Annual ITC-eligible operating expenses INCLUDING tax, CAD (for the regular-method comparison) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It implies a read-only calculation (comparison) but does not explicitly state no side effects, data modification risks, or authentication needs. Adequate for a non-destructive tool but lacking explicit safety disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-structured sentence that front-loads the main action and covers key aspects without redundancy. Every word earns its place.
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 lacks details about the comparison output format, constraints, or error handling. Adequate for a simple tool but leaves some gaps in expected return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. The description adds high-level context (e.g., 'revenue ceiling', 'excluded professions') but does not provide additional parameter-specific details beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: comparing GST/HST Quick Method to the regular method, covering eligibility, remittance, and financial comparison. It distinguishes from sibling tools like registration or deadline checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: it's for comparing two tax methods for Canadian small businesses. However, it does not explicitly state when not to use or list alternatives, though sibling context provides differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
instalment_planAInspectDetermine whether a Canadian individual must pay quarterly income-tax instalments (the $3,000 / $1,800-Quebec net-tax-owing tests) and compute all three CRA payment options (no-calculation, prior-year, current-year) as quarterly schedules with a suggested no-interest choice. Per the CRA's instalment calculation chart, 'net tax owing' EXCLUDES CPP contributions and EI premiums payable — pass those separately as cpp_payable and they are added to the instalment amounts only (chart line 24), never to the threshold test.
| Name | Required | Description | Default |
|---|---|---|---|
| quebec | No | Quebec resident (lower federal threshold; amounts cover the FEDERAL side only — Revenu Québec runs a separate instalment system, form TP-1026) | |
| cpp_payable | No | OPTIONAL: current-year CPP contributions and EI premiums payable on self-employment income, CAD. The CRA chart excludes this from the net-tax-owing threshold test but ADDS it to the instalment amounts (chart line 24). Ignored for Quebec residents — QPP/QPIP are billed by Revenu Québec, not the CRA. | |
| prior_year_owing | Yes | Net tax owing for the prior year, CAD (same chart basis: excludes CPP/EI payable) | |
| current_year_estimate | Yes | Estimated NET TAX OWING for the CURRENT year, CAD — per the CRA calculation chart: income tax minus amounts withheld, EXCLUDING CPP/EI payable on self-employment income (pass those in cpp_payable, do NOT include them here) | |
| second_prior_year_owing | Yes | Net tax owing two years ago, CAD (same chart basis: excludes CPP/EI payable) |
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 important behaviors: CPP/EI contributions are excluded from the threshold test but added to instalment amounts, Quebec residents have a separate system, and the tool suggests a no-interest choice. This is transparent 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately lengthy but well-structured: first sentence captures the main purpose, then details are provided. It earns its place by explaining the threshold test and Quebec-specific notes. Could be slightly more concise, but it's efficient for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 5 parameters and no output schema, the description covers the input logic thoroughly and explains key exclusions. However, it does not describe the return format of the quarterly schedules or the suggested choice, leaving some completeness gap. Still, it is mostly complete for an input-heavy tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description text largely mirrors the schema descriptions for parameters, adding only the context of the CRA chart exclusion. It does not significantly enhance understanding beyond what the schema already provides, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: determine if a Canadian individual must pay quarterly income-tax instalments using specific CRA tests and compute all three payment options as quarterly schedules. It is specific with verbs ('determine', 'compute') and resources ('quarterly income-tax instalments', 'CRA payment options'), and it distinguishes itself from sibling tools like cpp_self_employed or estimate_self_employed_tax 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool, mentioning the CRA's instalment calculation chart and the distinction for Quebec residents. However, it does not explicitly state when not to use it or suggest alternative tools. The context is strong, but lacking exclusion guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!
