Skip to main content
Glama
tresor4k

macalc

calculate_cheque_repas

Calculate Belgian meal voucher (cheque-repas) benefit: computes face value, employer/employee contributions, and monthly totals based on working days and contribution amounts.

Instructions

Calculate Belgian meal voucher (cheque-repas / maaltijdcheque) benefit. Returns: {face_value_per_voucher, employer_contribution_per_voucher, employee_contribution_per_voucher, monthly_total_vouchers, monthly_employer_cost, monthly_employee_contribution, ...}. See list_bundles for related 'finance-belgique' calculators.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
days_per_monthNoWorking days per month
employer_contributionNoEmployer contribution per voucher (max 6.91 EUR)
employee_contributionNoEmployee contribution per voucher (min 1.09 EUR)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultNoComputed result. Object whose fields depend on the tool (e.g. {tax, marginal_rate, brackets} for tax tools, {volume_l, gallons} for volume tools).
formulaNoHuman-readable formula or method used (e.g. "I=P·r·t", "Magnus formula").
sourceNoAuthoritative source for the rule or formula (e.g. "Article 197 CGI", "NF DTU 21").
reference_urlNoLink to a calcul2 page documenting the calculation in detail.
Behavior2/5

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

No annotations provided; description only mentions calculation and return values. Lacks disclosure of side effects, permissions, or constraints beyond schema.

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 concise sentences front-load key info: purpose and output. No wasted 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?

With output schema and 3 simple numeric parameters, description is adequate for a straightforward calculator. Would benefit from hinting at Belgian regulatory context.

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 describes all 3 parameters with defaults and constraints (100% coverage). Description adds no extra meaning beyond listing output fields. Baseline 3 is appropriate.

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?

Description specifies exact resource ('Belgian meal voucher (cheque-repas / maaltijdcheque) benefit') and verb ('Calculate') with explicit output fields, distinguishing it from siblings.

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

Usage Guidelines3/5

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

Mentions related 'list_bundles' for other calculators but no explicit when-to-use or when-not-to-use guidance. Usage context is implied by tool name.

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/tresor4k/macalc-mcp'

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