Skip to main content
Glama

UK Data: Finance formulas

calculate_tax

Read-onlyIdempotent

Calculates the tax amount by applying a tax rate percentage to an income or price amount. Formula: amount × (rate / 100). (cost: 1 credit)

Input Schema

NameRequiredDescriptionDefault
incomeNonumber, required, income or price amount, currency units, no default
tax_rateNonumber, required, tax rate percentage, plain number (10 = 10%), no default

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely new context with the explicit formula and the '(cost: 1 credit)' notice, which appears nowhere in structured fields. However, rounding and precision behaviour, a material concern for a money calculation, are left undisclosed.

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

Conciseness5/5

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

Two short sentences, front-loaded with the operation and immediately followed by the formula the agent needs, then the credit cost. Nothing is padded and nothing is buried.

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 two-parameter arithmetic tool with full schema coverage and no output schema, the description plus schema is nearly sufficient to call it correctly. The only meaningful omission is rounding/precision and currency handling of the returned tax amount.

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 both parameters (income, tax_rate) are already documented, including the '10 = 10%' convention. The formula restates the relationship between the parameters in a compact way but adds no constraint or edge-case meaning beyond the schema, so the baseline 3 applies.

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

Purpose4/5

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

States a specific verb and resource ('Calculates the tax amount') plus the exact operation performed on the two inputs, so the agent knows precisely what comes back. It does not distinguish itself from nearby siblings such as vat, calculate_discount, calculate_tip or stamp_duty, all of which take an amount and a percentage rate.

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

Usage Guidelines2/5

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

There is no statement of when to prefer this tool over vat or calculate_discount, nor any prerequisite or exclusion. The agent is given the mechanics of the computation but no routing guidance in a sibling set dense with percentage-of-amount calculators.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources