+----------------------------------------------------------------------+
| Aus Accounting MCP |
+----------------------------------------------------------------------+
| MCP server for AU tax review engines |
+----------------------------------+-----------------------------------+
| DR what it gives you | CR what it needs |
+----------------------------------+-----------------------------------+
| MCP tools for AU tax review | an MCP capable host client |
| delegates to reviewed engines | uv or uvx to install it |
| synthetic SBR test fixtures | - |
+----------------------------------+-----------------------------------+
30秒のデモ · インストール · クライアント設定 · ツールリファレンス · リリースノート
Aus Accounting MCP は、レビュー済みのオーストラリアの計算会計エンジンに対するローカルMCPファサードです。Claude Desktop、Claude Code、Cursor、Codex、Antigravity と互換性があります。
Payday Super は実験的なレビューであり（コンプライアンス判定ではありません）。Division 7A は拒否されます - 返済計算機はありません。SBR ペイロードは合成フィクスチャです。
[!WARNING] 税務アドバイスではありません。 このサーバーは構造化された結果、拒否、引用を返します。申告は行わず、登録エージェントの代わりにはなりません。DISCLAIMER.md を参照してください。
これは計算MCPであり、ホスト型ATO文書ストアではありません。オペレーターが提供する数値（Payday Super のタイミング、ATO の小規模事業ベンチマーク比率）に法定テストを適用し、Division 7A を拒否します。裁定を調べるには、文書検索MCPを使用してください。比較: AIエージェント向けオーストラリア税務ツール。
このサーバーは税法を再実装しません。Payday Super と ATO の小規模事業ベンチマークは以下に委任されています:
payday-super-checker (payday-super-checker)
ato-benchmark-compare (ato-benchmark-compare)
Division 7A は、レビュー済みエンジンが存在するまで拒否されます。SBR ペイロードは合成フィクスチャであり、申告ではありません。
stdio サーバーを起動せずに、作成されたデモを実行します:
uvx --from aus-accounting-mcp aus-accounting-mcp-demoチェック済みのテキストトランスクリプト checked text transcript は、アニメーションのアクセシブルな情報源です。その登録済みMCP呼び出しは、synthetic true と not_a_lodgment true を持つ合成BASフィクスチャを返し、その後、ERR_POLICY_DIV7A_REFUSED による意図的な Division 7A 拒否を返します。
期待される構造化成功:
synthetic: true
not_a_lodgment: true
form_type: BAS_AU_ACTIVITY_STATEMENT
summary.total_payable_to_ato: "42500.00"期待される構造化拒否:
code: ERR_POLICY_DIV7A_REFUSED
available: false
reviewed_engine: falseこの例は作成されたものであり、申告ではなく、税務アドバイスでもなく、重要な会計アクションの前に人間のレビューが必要です。クライアントデータを使用せず、外部サービスにも接触しません。
名前マッピング: 公開名 Aus Accounting MCP; リポジトリ au-tax-mcp-server; Python ディストリビューション aus-accounting-mcp; stdio MCP 実行可能ファイル aus-accounting-mcp; デモ実行可能ファイル aus-accounting-mcp-demo; MCP レジストリ ID io.github.ryanduguid/aus-accounting。
正規のリリースと互換性の参照: CI, v0.1.6 リリース, PyPI 0.1.6, MCP レジストリ 0.1.6, および compatibility.json。ターゲットが解決され、互換性レコードと一致した場合にのみ、バージョンを公開済みとして扱います。レコードはエンジンが管理するソースとリリースをリンクします。ランタイムの law_content_date とソースはエンジン所有のままです。
Related MCP server: Accounting Practice MCP Server
Python 3.10+ と uv が必要です。このサーバーとそのエンジンは PyPI に公開されています。サーバーはレビュー済みエンジンを正確なバージョンに固定しています:
バージョン管理された来歴には CITATION.cff と v0.1.6 リリースレコード を使用してください。依存する前にターゲットを検証してください。
uvx aus-accounting-mcpローカルの編集可能なツリーが必要な場合は、クローンして pip install . も引き続き機能します。
標準設定は、ローカル stdio MCP サーバーを実行するホストで動作します:
{
"mcpServers": {
"aus-accounting": {
"command": "uvx",
"args": [
"aus-accounting-mcp"
]
}
}
}既製のコピーは clients/ にあります。
または、標準設定を ~/.cursor/mcp.json に配置します。
標準設定を claude_desktop_config.json に貼り付けます（Windows では %APPDATA%\Claude\、macOS では ~/Library/Application Support/Claude/）。
claude mcp add aus-accounting -- uvx aus-accounting-mcpcodex mcp add aus-accounting -- uvx aus-accounting-mcpツール | 説明 | エンジン |
| 出荷されたATO事業タイプを一覧表示または検索 | ato-benchmark-compare |
| オペレーターが提供したバケット合計をATO範囲と比較 | ato-benchmark-compare |
| 1つの拠出をPayday Superのタイミングに対してレビュー | payday-super-checker |
| 拒否を返します。レビュー済みのDiv 7Aエンジンは接続されていません | none |
| エージェントテスト用の合成CTR/BAS（ | local fixture |
calc_payday_super_deadline は as_at を必要とします。クリアリングハウスの遅延を発明せず、LCR 2026/1 の移行割り当てを確認できません。送金日だけでは ON_TIME を生成できません。省略されたATO経費バケットは not_supplied であり、ゼロではありません。
金額は10進文字列であり、有限で、小数点以下最大2桁、AUD 1,000,000,000,000.00 以下です。日付は ISO-8601 です。Payday Super は payday-super-checker の全国 SGAA 1992 s 6(1) カレンダーを使用します。
エージェントに尋ねる:
Compare these P&L buckets to the ATO small-business benchmarks for this industry. Omit buckets I have not supplied. Do not treat missing as zero.Review this Payday Super contribution. QE day, remitted date, and fund-receipt date are in the CSV. as_at is today. Do not invent an SGC charge.MITライセンス。Ryan Duguid によって作成されました。境界声明: DISCLAIMER.md。発見コピー: docs/DISCOVERY.md。引用: CITATION.cff。
Review one contribution against payday-super-checker.
qe_day is the qualifying-earnings (payday) date. as_at is required. received is fund receipt. remitted is the day money was sent. This tool does not invent clearing-house latency and cannot confirm LCR 2026/1 transition allocation. Without a fund-receipt date the statutory test cannot return ON_TIME. Dates are ISO-8601. Amounts are decimal strings.
| Name | Required | Description | Default |
|---|---|---|---|
| as_at | Yes | ||
| qe_day | Yes | ||
| received | No | ||
| remitted | No | ||
| sg_amount | Yes | ||
| db_interest | No | ||
| employee_id | No | mcp-1 | |
| out_of_cycle | No | ||
| first_to_fund | No | ||
| next_standard_qe_day | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It explicitly discloses important limitations: the tool does not invent clearing-house latency, cannot confirm LCR 2026/1 transition allocation, and cannot return ON_TIME without a fund-receipt date. This is far more transparent than a typical description, though it does not address side effects or authentication.
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 compact and information-dense; each sentence contributes either a parameter definition, a format rule, or a limitation. The main purpose is stated clearly in the first sentence. The ordering could be slightly improved, but there is no padding.
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 domain-specific tool with 10 parameters and no annotations, the description covers required inputs and key behavioral caveats but leaves most optional flags opaque. An agent would need significant outside domain knowledge to correctly set db_interest, out_of_cycle, first_to_fund, next_standard_qe_day, or employee_id. The output schema exists, but the input side is incomplete.
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 0%, so the description must compensate by explaining parameters. It explains qe_day, as_at, received, and remitted, and notes ISO-8601 dates and decimal strings, but 6 of 10 parameters, including sg_amount, db_interest, out_of_cycle, first_to_fund, next_standard_qe_day, and employee_id, remain effectively unexplained or only given by their schema titles.
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 has a specific verb and resource: 'Review one contribution against payday-super-checker,' which aligns with the tool name and the statutory/ON_TIME language. It is distinguishable from the unrelated sibling tools. However, 'payday-super-checker' itself is not elaborated, so a non-domain agent is left inferring the exact computation.
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 intended use is implied: assess a contribution against the payday-super deadline. It provides useful input guidance such as as_at being required and received/remitted semantics, but it does not explicitly say when to choose this tool over an alternative 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.
Generate a synthetic CTR or BAS fixture. Not a lodgment and not statutory advice.
| Name | Required | Description | Default |
|---|---|---|---|
| form_type | Yes | ||
| entity_name | No | Synthetix Pty Ltd | |
| revenue_or_sales | No | 1000000.00 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It usefully discloses that the output is synthetic and non-lodgment, non-statutory-advice, but it doesn't mention side effects, persistence, or what the returned fixture corresponds to. The disclaimers are valuable but limite d.
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 short sentences, front-loaded with the verb and resource, and no waste. Each sentence earns its place, with the negative disclaimers adding useful boundary information in a compact form.
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 small tool with an output schema and defaults on two params, the description is mostly adequate for a basic call, but it leaves the meaning of parameters and the intended use scenario implicit. The unexanded acronym CTR and absence of any alternative routing guidance mean a genuinely complete context woul d need more.
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 0%, so the description must compensate. 'CTR or BAS' gives a hint abou t the possible form_ty pe values, but entity_name and revenue_or_sales receive no explanation beyond their names and defaults. The description does not meaningfull y explain the required parameter or the two optional ones.
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 states a specific action ('Generate') and resource ('synthetic CTR or BAS fixture'), so the tool's core purpose is clear. It also adds 'Not a lodgment and not statutory advice', which helps distinguish it from real submission tools, though it doesn't explicitly differentiate among the listed siblings.
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 use for creating synthetic test fixtures and explicitly says it is not a lodgment or statutory advice, providing a useful wnen-not cue. However, it offers no explicit guidance about when to choose this tool over siblings or what workflow it fits into.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare bucket totals against ATO small-business benchmarks.
Amounts are decimal strings. industry is an ATO business-type name (see list_ato_benchmark_industries). other_income is needed for any ratio: the ATO turnover rule reads it to choose the denominator, so without it every ratio is not_supplied. Pass 0 only where the operator established the business has no other income. This is a comparison, not a finding that anything is wrong. Uses ato-benchmark-compare.
| Name | Required | Description | Default |
|---|---|---|---|
| w1 | No | ||
| rent | No | ||
| year | No | ||
| industry | Yes | ||
| turnover | Yes | ||
| other_income | No | ||
| salary_wages | No | ||
| cost_of_sales | No | ||
| motor_vehicle | No | ||
| other_expense | No | ||
| associated_persons | No | ||
| cost_of_sales_labour | No | ||
| contractor_commission | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does this well by disclosing the denominator rule ('without it every ratio is not_supplied'), the special zero-passing caveat for other_income, and the non-judgmental nature ('This is a comparison, not a finding that anything is wrong'). It does not mention rate limits or side effects, but for a comparison 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?
The description is front-loaded with the core purpose and each sentence adds useful context. The final sentence 'Uses ato-benchmark-compare' is an implementation detail that adds little for an AI agent, but it is not harmful. Overall the description is dense and efficient without being bloated.
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 13 parameters and no annotations, the description covers the essential context: purpose, value formats, industry source, the other_income dependency, and the fact that this is a benchmark comparison rather than a finding. An output schema exists, so return-value details are not required. It could be slightly more explicit about year and other optional bucket semantics, but the current level is largely complete for correct invocation.
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 0%, so the description must compensate. It adds meaningful semantics: amounts are decimal strings, industry is an ATO business-type name, and other_income affects ratio calculation. It does not individually explain every bucket parameter, but 'bucket totals' plus the schema titles provides reasonable coverage for the remaining fields.
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 opens with a specific verb and resource: 'Compare bucket totals against ATO small-business benchmarks.' This clearly distinguishes the tool from siblings like list_ato_benchmark_industries, which lists industry names, and get_div7a_benchmark_rate, which deals with a different benchmark. The added note 'This is a comparison, not a finding' further sharpens the purpose.
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 gives clear context on when to use the tool and how to prepare inputs, such as referencing list_ato_benchmark_industries for valid industry names and explaining that other_income is required for any ratio. It does not explicitly state when not to use this tool versus alternatives, but no obvious alternative provides the same comparison functionality, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the reviewed s 109N(2) rate for a year, or UNKNOWN.
Years use the YYYY-YY form, such as 2026-27. The delegated engine fails closed outside its reviewed frozen table and does not read the network. response_detail defaults to summary; pass full for the complete provenance and statutory trace.
| Name | Required | Description | Default |
|---|---|---|---|
| year_of_income | Yes | ||
| response_detail | No | summary |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses fail-closed behavior, frozen reviewed data, no network access, the UNKNOWN sentinel, and response_detail options. These traits help an agent predict execution context and trust boundaries.
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?
Three sentences with no fluff. The purpose is front-loaded, followed by essential format guidance and behavior details. Every sentence earns its place and the structure is easy to scan.
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 two-parameter rate lookup, the description is complete: it states the returned value, year format, failure mode, network isolation, and response_detail behavior. Since an output schema exists, detailed return-shape documentation is not required here.
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 0%, so the description must compensate. It explains the required year format with an example (YYYY-YY, e.g., 2026-27) and clarifies the response_detail enum semantics: summary is default, full returns provenance and statutory trace. Both parameters receive meaningful explanation.
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?
States a specific verb and resource: 'Return the reviewed s 109N(2) rate for a year, or UNKNOWN.' This precisely identifies the tool's function and distinguishes it from sibling tools like get_ato_benchmarks or list_ato_benchmark_industries by referencing the specific statutory rate.
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 gives clear input-format guidance and behavioral context, but does not explicitly state when to prefer this tool over alternatives or mention any exclusion cases. Usage is implied rather than directly contrasted with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List ATO small-business benchmark industries from ato-benchmark-compare.
Pass search to filter by name. year is an optional benchmark year such as 2023-24; omit it to use the latest shipped dataset.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| search | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the behavioral burden. It discloses the data source and the default behavior when year is omitted, but it does not characterize read-only status, side effects, error cases, or result handling beyond what the output schema already covers.
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 compact: a one-sentence purpose followed by two short parameter-behavior notes. Every sentence adds value and the core action is front-loaded.
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 is simple, has an output schema to describe return shape, and the description covers source, purpose, and parameter behavior. It could briefly point users toward get_ato_benchmarks for retrieving actual benchmark values, but that is not necessary to invoke this tool correctly.
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 0%, so the description must compensate. It does explain both parameters: search filters by name, and year is an optional benchmark year with a concrete example and fallback behavior. It could be more precise about accepted year formats, but it is sufficient for correct invocation.
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?
Description states a specific verb ('List'), resource ('ATO small-business benchmark industries'), and data source ('ato-benchmark-compare'). It is clearly differentiated from the sibling get_ato_benchmarks by focusing on the industries list rather than benchmark values.
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?
Clear context is provided for both optional parameters: search filters by name, and year selects a benchmark year with a defined default when omitted. The description does not explicitly name alternatives or exclusions, but for a simple list operation the usage intent is obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refuse Division 7A matters outside the reviewed loan/MYR scope.
| Name | Required | Description | Default |
|---|---|---|---|
| start_fy | No | ||
| borrower_name | Yes | ||
| loan_principal | Yes | ||
| is_secured_25_year | No | ||
| lender_entity_name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of explaining behavior, but 'refuse' is ambiguous: does it return a rejection, raise an error, or record a refusal? It also does not explain what happens to in-scope matters or what 'MYR' means. The operational effect is under-specified.
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, front-loaded sentence with no filler. It is concise and to the point, though the cryptic 'MYR' slightly hurts precision. Overall it earns its place without waste.
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 five parameters, no annotations, and zero schema description coverage, this description is not enough for reliable tool use. It provides a useful scope rule, but the agent still needs to infer what 'refuse' does, what the parameters mean, and how this connects to the reviewed loan workflow. The presence of an output schema helps but does not fill these gaps.
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 0%, and the description adds no information about any of the five parameters. It does not clarify 'loan_principal' format, the meaning of 'start_fy', or how 'is_secured_25_year' affects the refusal decision. The description completely fails to compensate for the missing schema 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 states a specific action ('Refuse Division 7A matters') and a clear scope condition ('outside the reviewed loan/MYR scope'). It distinguishes itself from likely sibling review_div7a_loan by implying this is the negative decision path, though 'MYR' and 'reviewed loan' are not defined.
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 phrase 'outside the reviewed loan/MYR scope' gives an explicit condition for when this tool should be used: when a Division 7A matter falls outside the already-reviewed scope. It does not explicitly name alternative tools, but the scope condition effectively separates it from review_div7a_loan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Review one operator-supplied amalgamated Division 7A loan.
The tool runs the s 109N gate and then the s 109E minimum yearly repayment. Unknown facts may be omitted or passed as null; they remain UNKNOWN and are never coerced to false or zero. Amounts and rates are decimal strings. response_detail defaults to summary; pass full for the complete engine audit.
| Name | Required | Description | Default |
|---|---|---|---|
| loan_id | No | mcp-div7a-1 | |
| year_loan_made | No | ||
| year_of_income | Yes | ||
| response_detail | No | summary | |
| written_agreement | No | ||
| maximum_term_years | No | ||
| remaining_term_years | No | ||
| security_coverage_at_first_made | No | ||
| payments_applied_during_the_year | No | ||
| terms_in_place_before_lodgment_day | No | ||
| interest_rate_for_years_after_year_loan_made | No | ||
| amalgamated_loan_unpaid_at_end_of_previous_year | No | ||
| secured_by_registered_mortgage_over_real_property | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does meaningful work: it discloses that unknown facts remain UNKNOWN and are never coerced to false or zero, that amounts and rates are decimal strings, and that `response_detail` defaults to summary unless `full` is requested. This adds valuable behavioral context beyond anything the schema provides, though it does not mention side effects or authorization expectations.
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 well-structured: the primary purpose is front-loaded, followed by the engine behavior, then the crucial data-handling conventions, then the response-detail option. Every sentence earns its place and there is no 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?
For a domain-specific tool with 13 parameters and an output schema, the description covers the most important non-obvious details: unknown/null handling, decimal string types, and the `full` audit option. It does not explain the exact input format for `year_of_income` or clarify how the engine gates affect results, but the output schema and parameter titles reduce the missing surface.
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 0%, so the description must compensate for undocumented parameters. It provides cross-cutting semantics useful across many parameters: null means unknown, amounts/rates are decimal strings, and `response_detail` has a default and a `full` alternative. However, it does not explain individual parameter formats such as `year_of_income` or `loan_id`, leaving some burden on titles and defaults.
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 opens with a specific verb and resource: 'Review one operator-supplied amalgamated Division 7A loan.' It clearly names the tool's core function and scope, and the mention of 'one' loan distinguishes it from list or benchmark tools. However, it does not explicitly contrast itself with the closely named sibling `refuse_div7a`, so it stops short of full sibling differentiation.
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 context by describing what the tool does and the engine steps it runs ('s 109N gate' and 's 109E minimum yearly repayment'). However, there is no explicit statement about when to use this tool versus alternatives such as `refuse_div7a` or the benchmark tools, and no exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The benchmark pair (list industries vs get benchmarks) is clearly separated, and the super deadline, Division 7A refusal, and synthetic fixture tools occupy distinct niches. There is minor potential for confusion between list_ato_benchmark_industries and get_ato_benchmarks, but the descriptions resolve it.
All tool names follow a consistent snake_case verb_noun pattern: list, get, calc, refuse, generate. The style is predictable and readable across the set.
Five tools is a reasonable count for a focused server, but one tool is explicitly a refusal placeholder and another generates synthetic fixtures, so the effective functional surface is a bit thinner than the count suggests.
The set covers a few isolated AU-tax scenarios but is not a coherent tax surface. The most obvious gap is Division 7A, which is explicitly refused, and there are no broader tax calculation or lodgment workflows to support the server's apparent domain.
Australian identifier validation, GST arithmetic, fuzzy name matching, OFAC sanctions screening.
Australian tax knowledge base for agents: 34,500+ ATO documents, cited answers to any tax question.
Australian business-day and public-holiday calculations for AI agents and applications.
Open-source AI accounting skills verified by licensed accountants (tax, VAT, payroll).
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ryanduguid/australian-accounting'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
