Skip to main content
Glama

get_tax_estimate

Read-onlyIdempotent

See current tax estimates, missed-tax payment guidance, and your latest weekly statement (Shows outstanding_bounties: current full empire settlement amounts including missed taxes and other crimes. Use pay_bounty remotely to clear an empire balance; prepay_tax only covers future assessments. latest_statement contains the last completed weekly calculation when available. inactivity_exempt identifies characters currently eligible to skip weekly tax; gameplay or taxable earnings before assessment removes the exemption. Skipped tax is never charged later, and existing debt remains. next_assessment_approx_seconds uses remaining ticks and the current tick duration; pauses or rate changes affect actual timing. Read get_guide with guide=taxes for calculations and payment examples. Returns the income-tax assessment you would face if the weekly cycle ran this instant (taxable income accrued since your last assessment, per-empire breakdown with foreign-tax deductions, total owed), the property-tax assessment against your assessed_property_value (hull + fitted modules across every ship you own, computed via the same CalculateFittedShipValue helper used by insurance and salvage; bills the full rate per citizenship empire independently with no mutual-deduction credits), and the current sales-tax rate every empire would charge you at buy time. The taxable_income_by_source array splits your pending taxable income across the six activity categories that count: mission (mission rewards including distress completions), market (selling goods to NPCs or via exchange order fills), salvage (selling salvaged wrecks), ship_sale (selling a ship to any buyer), facility_sale (selling a facility), rescue (rescue payouts). The assessed_property_by_ship array shows each owned ship's contribution to the total assessed value. Gifts, refunds, insurance payouts, and treasury subsidies are not taxable and do not appear. When an empire publishes a progressive schedule (income or property), its row carries a brackets array showing the marginal rate, your income/value, and the tax produced for each bracket. last_property_assessed_at is stamped at the end of every weekly property cycle even when zero owed. All rate_bps fields are basis points: 100 = 1%, 10000 = 100%. Pure read — no escrow, no notifications.)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
session_idYesYour session ID from login/register

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/idempotent hints, it discloses no escrow/no notifications, that skipped tax is never charged later, that inactivity exemption is lost on certain earnings, that timing estimates can be affected by pauses or rate changes, and that last_property_assessed_at is stamped even when zero is owed. These are concrete behavioral details not visible in the annotations.

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?

The description is long, but it is front-loaded with a summary sentence and organized into returns, field semantics, exclusions, and caveats. The length is justified by the absence of an output schema; still, it could be tightened.

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

Completeness5/5

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

For a complex tax-estimate tool with no output schema, the description covers returned fields, tax categories, non-taxable income, progressive-rate brackets, basis-point interpretation, edge cases, and related commands. An agent has enough information to interpret the result and decide whether to call a sibling tool.

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 coverage is 100% and the single session_id parameter is already documented in the schema. The description does not add parameter-level meaning, so the baseline of 3 applies.

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?

The description opens with a specific verb-resource summary ('See current tax estimates, missed-tax payment guidance, and your latest weekly statement') and then enumerates exactly what the tool returns. It also routes around sibling tax tools by naming pay_bounty, prepay_tax, and get_guide, so an agent can tell it apart.

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

Usage Guidelines5/5

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

It explicitly states when not to use alternatives: 'Use pay_bounty remotely to clear an empire balance; prepay_tax only covers future assessments' and 'Read get_guide... for calculations and payment examples.' This tells an agent when this read-only tool is the right choice and when a different tool is needed.

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