Skip to main content
Glama
Sign In

au-compliance-kit

by io.github.aftertaxau
OverviewDiscussionsAdmin

Super guarantee

super_guarantee
Read-onlyIdempotent

Australian superannuation guarantee (12%) an employer must pay on ordinary time earnings, or the split of a total package that includes super into base salary and super (package divided by 1.12). Use it for 'how much super is paid on $X' or 'what is the base salary in a $X package'. Returns AUD amounts. Doesn't apply the maximum super contribution base. Read-only and deterministic.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "amount": "<amount>"
    },
    "name": "super_guarantee"
  }
}

Input Schema

NameRequiredDescriptionDefault
amountYesEarnings (AUD), or the total package if includesSuper is true.
includesSuperNoamount is a package that includes super. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so 'read-only and deterministic' largely restates structured data. The genuinely additive parts are the fixed 12% rate, the AUD return currency, and the caveat that the maximum contribution base is not applied — real behavioral context, but modest.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the definition and formula, then the usage examples, then the caveats — a logical order with no filler. The trailing 'Read-only and deterministic' sentence is partly redundant with the annotations, keeping it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter calculator with full annotation coverage, the description covers purpose, both modes, currency, and the main scope limitation. Only minor gaps remain, such as rounding/precision of the returned AUD amounts.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters, establishing a baseline of 3. The description's two example phrasings clarify what each mode yields (super amount vs. base salary split), but it adds no format, rounding, or edge-case detail for `amount`.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource with the exact formula (12% of ordinary time earnings, or package / 1.12), which cleanly separates it from the income-tax and withholding siblings. An agent can tell instantly that this is the superannuation calculator, not a tax estimate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete trigger phrasings ('how much super is paid on $X', 'what is the base salary in a $X package') that map to the two modes, and states an explicit exclusion (does not apply the maximum super contribution base). It does not name a sibling alternative for the cases it excludes, 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.

All au-compliance-kit toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources