Compute 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.
Add one secure layer between your agents and this server.
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.
