groTAX by Grovisor

groTAX: compute UAE Corporate Tax

grotax_compute_ct

Read-onlyIdempotent

Estimate UAE Corporate Tax using the Grovisor computation (rows A–K): AED 375,000 0% band then 9%, 50% entertainment add-back, interest cap (higher of AED 12m or 30% of adjusted EBITDA), 75% loss relief, Small Business Relief, simplified QFZP and WHT/FTC credits. Only accountingProfit is required; pass revenue to test SBR. Returns a markdown table plus structured rows. Indicative, not tax advice.

Input Schema

TableJSON Schema

Name	Required	Description
`ftc`	No	Foreign tax credit, AED
`mne`	No	Member of a multinational group (blocks SBR)
`wht`	No	Withholding tax credit, AED
`qfzp`	No	Treat as a Qualifying Free Zone Person (simplified: 0% on qualifying income)
`fines`	No	Fines and penalties (non-compensatory), AED
`ebitda`	No	Tax-EBITDA, AED, for the 30% interest cap. Leave out to have it calculated from taxable income + net interest + depreciation
`revenue`	No	Revenue for the tax period, AED (drives Small Business Relief and audit checks)
`lossesBF`	No	Tax losses brought forward, AED
`sbrElect`	No	Elect Small Business Relief if eligible
`donations`	No	Donations to non-qualifying bodies, AED
`periodEnd`	No	Tax period end date, YYYY-MM-DD (default 2025-12-31)
`interestBF`	No	Net interest disallowed in earlier periods and carried forward, AED (deducted within this period's cap)
`netInterest`	No	Net interest expense, AED
`depreciation`	No	Depreciation and amortisation, AED (used to calculate tax-EBITDA when ebitda is not given)
`entertainment`	No	Total client entertainment expense, AED (50% is added back)
`naturalPerson`	No	The business is owned by an individual (sole establishment or civil company of a natural person)
`otherAddBacks`	No	Other non-deductible expenses, AED
`ownerDrawings`	No	Owner's drawings or salary booked as expenses, AED (added back only when naturalPerson is true)
`associateShare`	No	Equity-accounted share of profit (+) or loss (-) of associates and joint ventures, AED (taken out)
`connectedExcess`	No	Payments to connected persons above market value, AED
`exemptDividends`	No	Exempt dividends from UAE/free zone companies, AED
`otherDeductions`	No	Other allowable deductions, AED
`unrealisedGains`	No	Net unrealised gain (+) or loss (-) in the accounts, AED (adjusted only when realisationElect is true)
`accountingProfit`	Yes	Net profit (or loss, negative) per the financial statements, AED
`qualifyingIncome`	No	QFZP qualifying income taxed at 0%, AED
`realisationElect`	No	Elected to tax gains and losses on realisation rather than as booked
`connectedPayments`	No	Total paid to connected persons in the period, AED (raises the transfer pricing disclosure warning above AED 500,000)
`dividendsExpensed`	No	Dividends or profit distributions booked as expenses, AED (always added back)
`foreignTaxExpensed`	No	Foreign and withholding taxes booked as expenses, AED (added back)
`participationIncome`	No	Participation exemption income, AED
`exemptIncomeExpenses`	No	Expenses relating to exempt income, AED
`revenueExceededBefore`	No	Revenue exceeded AED 3m in an earlier CT period (blocks SBR permanently)

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedOct 6, 2026

addedInput schema / properties / associateShare

Added value: +{
+  "description": "Equity-accounted share of profit (+) or loss (-) of associates and joint ventures, AED (taken out)",
+  "type": "number"
+}

addedInput schema / properties / connectedPayments

Added value: +{
+  "description": "Total paid to connected persons in the period, AED (raises the transfer pricing disclosure warning above AED 500,000)",
+  "type": "number"
+}

addedInput schema / properties / depreciation

Added value: +{
+  "description": "Depreciation and amortisation, AED (used to calculate tax-EBITDA when ebitda is not given)",
+  "type": "number"
+}

addedInput schema / properties / dividendsExpensed

Added value: +{
+  "description": "Dividends or profit distributions booked as expenses, AED (always added back)",
+  "type": "number"
+}

changedInput schema / properties / ebitda / description

Previous value: -"Adjusted (tax) EBITDA, AED — used for the 30% interest cap"New value: +"Tax-EBITDA, AED, for the 30% interest cap. Leave out to have it calculated from taxable income + net interest + depreciation"

addedInput schema / properties / foreignTaxExpensed

Added value: +{
+  "description": "Foreign and withholding taxes booked as expenses, AED (added back)",
+  "type": "number"
+}

addedInput schema / properties / interestBF

Added value: +{
+  "description": "Net interest disallowed in earlier periods and carried forward, AED (deducted within this period's cap)",
+  "type": "number"
+}

addedInput schema / properties / naturalPerson

Added value: +{
+  "description": "The business is owned by an individual (sole establishment or civil company of a natural person)",
+  "type": "boolean"
+}

addedInput schema / properties / ownerDrawings

Added value: +{
+  "description": "Owner's drawings or salary booked as expenses, AED (added back only when naturalPerson is true)",
+  "type": "number"
+}

addedInput schema / properties / realisationElect

Added value: +{
+  "description": "Elected to tax gains and losses on realisation rather than as booked",
+  "type": "boolean"
+}

addedInput schema / properties / unrealisedGains

Added value: +{
+  "description": "Net unrealised gain (+) or loss (-) in the accounts, AED (adjusted only when realisationElect is true)",
+  "type": "number"
+}

First observedOct 2, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare a safe, read-only, idempotent, non-destructive operation, so that burden is lifted. The description adds valuable context beyond annotations: it discloses the output format ('markdown table plus structured rows') and the important caveat 'Indicative, not tax advice.'

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 purpose is front-loaded and the dense tax-rule summary is appropriate for a 32-parameter computation tool. It is compact but not terse; every clause contributes a rule, required input, or output note.

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 high complexity (32 parameters) and absence of an output schema, the description does well: it specifies the required parameter, optional SBR input, key computation rules, return format, and a disclaimer. Some parameter-level nuance is left to the schema, which is fully documented.

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?

Schema description coverage is 100%, so the schema fully documents all 32 parameters. The description still adds meaning by explaining how some inputs drive the computation (e.g., 50% entertainment add-back, revenue drives SBR, WHT/FTC credits), going beyond bare parameter labels.

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: 'Estimate UAE Corporate Tax' and names the underlying computation method. This clearly separates it from sibling tools like grotax_get_rules or grotax_compare_sbr, though it does not explicitly call out those alternatives.

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?

Gives limited usage guidance by noting 'Only accountingProfit is required; pass revenue to test SBR.' However, it does not state when to prefer this tool over siblings such as grotax_compare_sbr or grotax_penalties, leaving the broader routing decision implicit.

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

All groTAX by Grovisor tools Inspect

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

Need Help?