Skip to main content
Glama
iseppo

e-arveldaja MCP Server

by iseppo

Check Tax-Free Limits

check_tax_free_limits
Read-onlyIdempotent

Compute cumulative TuMS §49 tax-free limits for representation and donations, and calculate 22/78 income tax on any excess using year-to-date payroll and profit.

Instructions

Compute cumulative TuMS § 49 tax-free limits (representation 50 €/month + 2% of payroll; donations 3% of payroll or 10% of prior-year profit) and the 22/78 income tax on any excess (rates date-gated). Pure calculator over caller-supplied year-to-date figures (payroll from the TSD declaration, prior-year profit from compute_profit_and_loss); it does not read the ledger.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
as_of_dateYesDate the cumulative figures are taken as of (YYYY-MM-DD). Sets the 22/78 rate and the default months elapsed.
ytd_donationsNoYear-to-date gifts/donations to listed associations. Omit to skip the donation limit.
donation_basisNoWhich donation limit to apply: 3% payroll, 10% prior-year profit, or the more favourable (default max).
months_elapsedNoCalendar months elapsed for the representation 50 €/month accrual. Defaults to the month of as_of_date.
prior_year_profitNoPrior financial year's profit (for the donation 10% alternative). Defaults to 0.
ytd_representation_costsNoYear-to-date representation/entertainment costs booked. Omit to skip the representation limit.
ytd_social_taxed_payrollYesYear-to-date payments subject to social tax (the 2%/3% base).
Behavior4/5

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

Annotations indicate read-only, idempotent, non-destructive. The description adds behavioral context: it is a pure calculator, uses caller-supplied figures, does not read the ledger, and has date-gated rates. This goes beyond annotations by explaining what the tool does not do and its dependencies.

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?

The description is concise (three sentences) and front-loaded with the primary function. Every sentence adds value: the first defines the computation, the second clarifies it is a calculator with dependencies, and the third states a negative behavior (does not read ledger). No unnecessary words.

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?

Given the complexity (7 parameters, no output schema), the description covers the calculation logic, defaults, and dependencies. However, it does not describe the output format or structure, which would be helpful for an agent to interpret results. Still, the core behavior is well explained.

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

Parameters4/5

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

The description explains the calculation rules for representation and donation limits, adding meaning beyond the schema descriptions (e.g., 'Omit to skip the donation limit' and how months_elapsed defaults). Schema coverage is 100%, so the description complements rather than repeats, but it could detail parameter interactions more.

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 clearly states the tool computes TuMS §49 tax-free limits and the 22/78 income tax on excess, with specific formulas (representation 50€/month + 2% payroll; donations 3% payroll or 10% profit). It distinguishes itself from sibling tools by being a pure calculator that does not read the ledger, and references dependencies like compute_profit_and_loss.

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?

The description implies usage context: it is a calculator over caller-supplied figures and does not read the ledger, so use when you have year-to-date data. It does not explicitly state when not to use or list alternatives, but the purpose is specific enough to avoid confusion with sibling tools.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/iseppo/e-arveldaja-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server