Checked calculators for money, tax, crypto, engineering and compliance, each with formula and source
Scored across 8 tools
The specialized compliance tools cover clearly distinct domains: breach notification, business filing, data requests, e-invoicing, and Gulf final settlement. The generic tools also have separate roles: search_tools for discovery, get_tool for metadata, and run_calculator for executing calculators. There is no meaningful overlap in purpose.
All names use snake_case and are descriptive, with no chaotic mixing of conventions. However, the pattern is not fully uniform: specialized tools use domain-oriented names ending in _deadline, _check, or _settlement, while generic tools use verb_noun names like get_tool and run_calculator.
Eight tools is a well-scoped set for a compliance and calculator service. Each tool has a clear role: discovery, metadata, generic execution, and several focused compliance calculators. There are no redundant filler tools.
The surface covers discovery, inspection, execution, and several major compliance workflows, which is strong for the apparent domain. A minor gap is the lack of an explicit list-all-tools operation; search_tools can find tools by topic, but an agent must already know a topic to discover everything available.
Work out the GDPR / UK GDPR Article 33 deadline for notifying a personal data breach: 72 elapsed hours from becoming aware, given as local time in the person's time zone (IANA zone with daylight saving, or a fixed UTC offset) and in UTC. Returns the deadline, which authority to notify (lead authority, every EU authority where affected people live, or the UK Information Commission), the steps for a controller or processor with their article references, official sources, last-checked date and page link. Uses GlanceDesk Jurisdiction's tested deadline module.
| Name | Required | Description | Default |
|---|---|---|---|
| role | Yes | controller = decides why and how the data is used; processor = handles the data for a client. | |
| aware | Yes | When the organisation became aware of the personal data breach: local date and time YYYY-MM-DDTHH:MM in time_zone (or utc_offset). | |
| scope | No | Which apply (any combination): eu_main = EU GDPR, main establishment in the EU; eu_none = EU GDPR, no establishment in the EU (serves EU users from outside); uk = UK GDPR, affected people in the UK. Empty or left out = all three. Decides which authority is notified. | |
| time_zone | No | IANA time zone of the person, e.g. "Europe/London", "Asia/Karachi", "America/Los_Angeles". Daylight saving time is applied. Give this or utc_offset; with neither, times are UTC. | |
| utc_offset | No | Fixed offset from UTC instead of time_zone, e.g. "+05:00" or "-04:00" (no daylight-saving changes). Default "+00:00" (UTC). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring this read-only, idempotent, non-destructive, and closed-world, the description adds useful behavioral context about what is returned: the deadline, authority to notify, controller/processor steps with article references, official sources, last-checked date, and page link. It does not discuss error handling or rate limits, but for a deterministic read-only calculator the transparency is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and calculation basis, then concisely covers return values and sourcing. It is dense but every clause earns its place and there is no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the return-value burden and does so fully: deadline in local and UTC time, authority, steps, article references, sources, and last-checked date. Given the read-only annotations and rich schema, an agent has enough information to call and interpret the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents role, aware, scope, time_zone, and utc_offset in detail. The description reinforces how local time and UTC offsets are handled and that scope decides which authority is notified, but it does not add syntax or edge-case meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-plus-resource formulation: it calculates the GDPR/UK GDPR Article 33 breach notification deadline and states the exact basis of the calculation (72 elapsed hours from awareness). It clearly distinguishes this from sibling deadline tools such as data_request_deadline and business_filing_deadline by naming the legal domain and the returned authority/steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when the tool applies: notifying a personal data breach under GDPR/UK GDPR, with role and scope determining authority. It does not explicitly name when not to use it or point to specific sibling alternatives, but the domain is sufficiently distinct that an agent can tell when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Work out a business tax filing deadline and estimate the late penalty: Pakistan income tax return (Income Tax Ordinance s.118 with official FBR extensions; s.182 penalty) and quarterly withholding statements (s.165), UAE Corporate Tax return and payment (9 months after the tax period; registration deadline under FTA Decision 3/2024; Cabinet Decision 75/2023 penalties), UAE VAT return and payment (28th day after the tax period; Cabinet Decision 40/2017 as amended by Cabinet Decision 129/2025), Saudi VAT tax period and due date (Implementing Regulations Arts. 58, 59, 62, 74; VAT Law penalties). Every line cites its legal reference and official source; unconfirmed facts are marked "Being verified" and not used. Uses GlanceDesk Jurisdiction's tested filing module.
| Name | Required | Description | Default |
|---|---|---|---|
| paid | No | Optional: date the tax was or will be paid (uae_corporate_tax, uae_vat with unpaid_tax; saudi_vat with vat_due). Date as YYYY-MM-DD. | |
| year | No | pk_withholding_statement: calendar year the quarter ends in, e.g. 2026. | |
| filed | No | Optional: date the return or statement was or will be filed (estimates the late-filing penalty). Date as YYYY-MM-DD. | |
| filing | Yes | Which deadline: pk_income_tax_return = Pakistan income tax return (Income Tax Ordinance s.118, penalty s.182); pk_withholding_statement = Pakistan quarterly withholding statement (s.165); uae_corporate_tax = UAE Corporate Tax return and payment (Federal Decree-Law 47/2022) with optional registration deadline; uae_vat = UAE VAT return and payment (VAT Executive Regulation Art. 64); saudi_vat = Saudi VAT tax period, return and payment (VAT Implementing Regulations Arts. 58, 59, 62). | |
| vat_due | No | saudi_vat, with filed or paid: VAT due for the period in SAR (to estimate the fines). | |
| period_end | No | uae_corporate_tax, uae_vat, saudi_vat: last day of the tax period (Saudi: a month end). Date as YYYY-MM-DD. | |
| unpaid_tax | No | uae_corporate_tax, uae_vat, with paid: tax paid late, in AED. | |
| tax_payable | No | pk_income_tax_return: tax payable for the year in PKR (the higher of assessed tax and the last duly filed year's tax). Needed with filed to estimate the late-filing penalty. | |
| incorporated | No | uae_corporate_tax, optional: date the business was set up (checks the FTA Decision 7/2024 postponement for first tax periods ending on or before 29 February 2024). Date as YYYY-MM-DD. | |
| tax_year_end | No | pk_income_tax_return: last day of the tax year (normal tax year ends 30 June, e.g. 2026-06-30 = tax year 2026; special tax years end on another month end). Date as YYYY-MM-DD. | |
| taxpayer_type | No | pk_income_tax_return: company; salaried = individual with 75% or more of income from salary; other = other individual or association of persons (AOP). | |
| monthly_approved | No | saudi_vat: true if ZATCA approved or directed a monthly tax period although supplies are not over SAR 40,000,000. | |
| quarter_end_month | No | pk_withholding_statement: month the quarter ends (3 = March, 6 = June, 9 = September, 12 = December). | |
| registration_type | No | uae_corporate_tax, optional (gives the registration deadline, FTA Decision 3/2024): res_new = resident company set up on or after 1 March 2024; res_old = resident company set up before 1 March 2024 (registration_start = issue date of its earliest licence); res_foreign = foreign company managed and controlled in the UAE (registration_start = end of its financial year); nr_pe = non-resident with a permanent establishment (registration_start = date the PE came into existence); nr_nexus = non-resident with a nexus (date the nexus was established); np_res = resident individual doing business with turnover over AED 1 million (a date in the calendar year the threshold was passed); np_nr = non-resident individual (date the conditions were met). | |
| registration_start | No | uae_corporate_tax, with registration_type: the date that starts the registration period (see registration_type). Date as YYYY-MM-DD. | |
| taxable_supplies_12m | No | saudi_vat: value of taxable supplies in the last 12 months in SAR (over SAR 40,000,000 = monthly tax period). | |
| repeat_within_24_months | No | uae_vat, with filed: true if a late return was already penalised in the previous 24 months. | |
| withheld_tax_paid_on_time | No | pk_withholding_statement, with filed: yes = the tax withheld or collected was paid by its due date; no = it was not; nil = no tax was required to be withheld or collected. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavior: every result line cites its legal reference and official source, and unconfirmed facts are marked 'Being verified' and excluded, which tells the agent how much to trust the output. It does not describe the return shape or how penalties are presented, and the closing 'Uses GlanceDesk Jurisdiction's tested filing module' is filler rather than disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and result ('Work out a business tax filing deadline and estimate the late penalty'), then the covered filings. It is dense but largely earns its space; the repeated statutory citations and the 'tested filing module' clause are the only real waste, since the same references appear in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 18-parameter, enum-rich read-only calculator with full schema coverage and no output schema, the description supplies the domain framing (which jurisdictions, penalties estimated, legal basis) an agent needs before wiring parameters. It stops short of describing the returned structure beyond 'every line cites its legal reference', which is a modest gap rather than a blocking one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all 18 parameters documented, including enums and per-filing applicability, so the schema carries the burden and baseline 3 applies. The description's legal citations (s.118, s.182, s.165, Cabinet Decision 40/2017, IR Arts. 58/59/62) duplicate citations already present in the schema's 'filing' enum description rather than adding new parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and outcome ('work out a business tax filing deadline and estimate the late penalty') plus the exact coverage: five named filings across Pakistan, UAE and Saudi Arabia. An agent can immediately tell this is the tax-filing-deadline calculator, distinct from the sibling deadline tools (breach_notification_deadline, data_request_deadline, gulf_final_settlement).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The enumeration of supported filings implicitly bounds scope, so an agent knows an out-of-scope filing needs another tool, and the schema pins each filing to its required inputs. However there is no explicit when-to-use/when-not guidance and no named alternative for adjacent cases (e.g. final settlement, e-invoicing compliance checks) among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Work out the deadline to answer a data subject or consumer request: EU GDPR and UK GDPR Article 12(3) (one month, extendable by two further months; UK Data (Use and Access) Act 2025 changes), or California CCPA/CPRA (confirm within 10 business days, respond within 45 days with one 45-day extension; opt-out or limit requests within 15 business days). Returns each date with its legal reference, the steps, official sources, last-checked date and page link. Uses GlanceDesk Jurisdiction's tested deadline module.
| Name | Required | Description | Default |
|---|---|---|---|
| law | Yes | eu = EU GDPR, uk = UK GDPR, ccpa = California CCPA/CPRA. | |
| received | Yes | Local date the request was received, YYYY-MM-DD. | |
| time_zone | No | IANA time zone of the person, e.g. "Europe/London", "Asia/Karachi", "America/Los_Angeles". Daylight saving time is applied. Give this or utc_offset; with neither, times are UTC. | |
| utc_offset | No | Fixed offset from UTC instead of time_zone, e.g. "+05:00" or "-04:00" (no daylight-saving changes). Default "+00:00" (UTC). | |
| request_type | No | CCPA only (required for ccpa): know = know/access, delete or correct; optout = opt out of sale/sharing, or limit use of sensitive data. Not used for eu or uk. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real context beyond them: the actual legal rules applied, that business days vs calendar months differ by regime, and what the payload contains (dates, legal reference, steps, sources, last-checked date, page link) — important since there is no output schema. It does not state the failure behavior if 'received' is a future or malformed date.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, then the regime rules, then the return shape — a sensible ordering. It is dense (long parenthetical legal citations) but nearly every clause carries information; the closing 'tested deadline module' line is the only piece that does not help an agent call the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly takes on the burden of describing return values and does so concretely. For a two-required-parameter computation tool this is nearly complete; only edge-case behavior and the interaction requirement (request_type mandatory when law='ccpa') are left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all five parameters. The description nonetheless adds semantic value the schema does not: it explains why request_type matters (opt-out/limit requests get 15 business days versus 45 days for know requests) and that business-day counting makes time_zone relevant. That is genuine meaning beyond the enum labels.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('work out the deadline to answer a data subject or consumer request') and scopes it to three named legal regimes with their statutory bases (EU/UK GDPR Art. 12(3), CCPA/CPRA). An agent can immediately tell this apart from breach_notification_deadline and business_filing_deadline, which concern different obligations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The legal regime and request-type breakdown imply when each mode applies, and the schema makes request_type='ccpa'-only explicit. However, there is no explicit routing guidance — nothing says 'for breach incidents use breach_notification_deadline' or 'do not use this for employee/HR data request timelines'. Usage is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether e-invoicing applies to a business and its deadline: Saudi ZATCA Phase 1 and Phase 2 waves, UAE e-invoicing phases (Ministerial Decisions 243 and 244 of 2025), Pakistan FBR electronic invoicing (S.R.O. 1852(I)/2025). Every line cites its legal reference and official source; unconfirmed facts are marked "Being verified" and not used.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | sa = Saudi Arabia (ZATCA), ae = United Arab Emirates (MoF/FTA), pk = Pakistan (FBR). | |
| revenue | No | UAE: gross revenue in the most recent accounting period (AED). | |
| resident | No | Saudi Arabia: is the business resident in Saudi Arabia? | |
| turnover | No | Pakistan: turnover declared in sales tax returns for the last twelve months (PKR). | |
| customers | No | Who you invoice: b2b = businesses, b2g = government, b2c = consumers. | |
| entity_type | No | UAE: business, or gov = government entity. | |
| business_type | No | Pakistan: public = public listed company, company = other company, individual = individual or association of persons. | |
| imports_goods | No | Pakistan: does the business import goods? | |
| vat_registered | No | Saudi Arabia or UAE: is the business registered for VAT there? | |
| revenue_by_year | No | Saudi Arabia: revenue subject to VAT (SAR) for each year the ZATCA waves use: 2022, 2023, 2024, 2025. Leave a year out if not trading. | |
| sales_tax_registered | No | Pakistan: registered for sales tax with the FBR? | |
| conducts_business_in_uae | No | UAE: does the person conduct business in the UAE? |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive behavior, and a closed-world scope. The description adds useful output-behavior context: every line cites a legal reference and official source, and unconfirmed facts are marked "Being verified" and not used.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and jurisdictions, and has no redundant or filler content. Every sentence contributes either scope or source-reliability information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the three supported jurisdictions, the relevant legal regimes, and the citation/verification policy for outputs. It does not fully explain the conditional country-specific parameter combinations or the exact return format, but the rich input schema carries most of that burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all twelve parameters are already documented in the schema, including country-specific meanings. The description adds jurisdictional and legal context but does not add parameter-level syntax or constraints beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: check whether e-invoicing applies and determine the deadline. It scopes the tool to Saudi ZATCA, UAE e-invoicing phases, and Pakistan FBR e-invoicing, which clearly separates it from generic filing-deadline sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the first clause: an agent should use this to check e-invoicing applicability and deadlines for the three named jurisdictions. However, the description does not explicitly say when not to use it or name alternatives such as business_filing_deadline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get everything about one GlanceDesk tool before running it: its inputs (types, units, options, min/max) as JSON Schema, outputs, formula or legal rule, official sources with URLs, last-checked date, disclaimer, page URL and a worked example computed by the tool itself.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Slug from search_tools, e.g. "uae-gratuity-calculator". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds useful behavioral context beyond that: the worked example is 'computed by the tool itself' and there is a last-checked date and disclaimer, telling the agent the payload reflects live-computed and dated authoritative content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that begins with the purpose and then enumerates the return payload, with no redundant or filler clauses.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by enumerating the returned fields (inputs schema, outputs, formula/rule, sources with URLs, last-checked date, disclaimer, page URL, worked example). Nothing material is missing for a one-parameter read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the slug parameter is already documented with an example in the schema. The description adds no further parameter semantics, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get everything about one GlanceDesk tool') and scopes it with 'before running it', which distinguishes it from the sibling run_calculator and from search_tools. An agent can tell exactly what this returns without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'before running it' gives a clear usage context: fetch metadata prior to execution. It does not name the alternatives (run_calculator, search_tools) explicitly or say when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Work out what a private-sector worker is owed when a job ends in Saudi Arabia, the UAE or Qatar: end-of-service award or gratuity, unpaid wages, unused leave and overtime, each line with its labour-law article, plus a claim summary. Uses GlanceDesk Jurisdiction's tested engine.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | sa = Saudi Arabia (Labor Law, Royal Decree M/51), ae = United Arab Emirates (Federal Decree-Law 33 of 2021, private sector), qa = Qatar (Labour Law, Law No. 14 of 2004). | |
| last_day | Yes | Last day of work, YYYY-MM-DD. Both days count as service. | |
| first_day | Yes | First day of work, YYYY-MM-DD. | |
| how_it_ended | Yes | employer = the employer ended the contract (not for misconduct); expired = fixed-term contract ended, not renewed; resign = the worker resigned; breach = the worker left because the employer broke the contract or law (Saudi Art. 81, UAE Art. 45); exception = Saudi only: force majeure, or a female worker leaving within 6 months of marriage or 3 months of giving birth; misconduct = dismissed without notice for a reason the law lists (Saudi Art. 80, UAE Art. 44, Qatar Art. 61). | |
| overtime_hours | No | Optional. Unpaid overtime hours. | |
| unused_leave_days | No | Optional. Unused annual leave days earned, including this year's share. | |
| basic_monthly_wage | Yes | Last basic monthly wage, without allowances (SAR, AED or QAR). The UAE and Qatar gratuity and leave pay use this. | |
| total_monthly_wage | Yes | Last total monthly wage: basic plus contractual allowances. The Saudi award and leave pay use this. Must be at least the basic wage. | |
| unpaid_wage_months | No | Optional. Months of wages not paid (decimals for part months). | |
| unpaid_absence_days | No | UAE only, optional: days of unpaid absence (not counted as service). | |
| night_overtime_hours | No | UAE or Qatar, optional: how many of the overtime hours were at night (UAE 10 pm to 4 am, Qatar 9 pm to 3 am; not for shift workers). | |
| normal_hours_per_day | No | Needed only with overtime: normal working hours per day in the contract. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond the read-only/idempotent annotations: each calculated line includes its labour-law article, and the tool returns a claim summary. This tells the agent what kind of output to expect and reinforces that the tool performs a legal calculation rather than a raw arithmetic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the purpose, scope, outputs and engine in a compact form. Every clause contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter calculation tool with no output schema, the description gives enough context about what is calculated and what comes back. The detailed legal inputs are fully handled by the schema, though the description could do slightly more to clarify output shape or exclusion behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so all 12 parameters are well documented in structured data. The description names the calculation components but does not add parameter-level detail beyond what the schema already provides; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: it works out what a private-sector worker is owed at job end, covering end-of-service award/gratuity, wages, leave and overtime. It also scopes the tool to Saudi Arabia, UAE and Qatar, making it clearly distinct from generic calculator and deadline siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states the triggering context: when a job ends in Saudi Arabia, UAE or Qatar. It does not explicitly name alternatives or exclusion cases, but the domain and situation are sufficiently specific for an agent to know when this tool applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run one GlanceDesk Calculators, GlanceDesk Crypto or GlanceDesk Compute calculator with the person's values and get the tested answer with units, a one-sentence explanation, the formula, official sources, last-checked date, page URL and disclaimer. Invalid or missing values return the calculator's own error message; nothing is guessed or filled in.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Calculator slug (see search_tools / get_tool). | |
| inputs | Yes | Field id to value, as listed by get_tool. Numbers may be given as numbers or as text like "10,000"; dates as YYYY-MM-DD; options by their value. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, so the description appropriately focuses on added behavioral context: exact output contents, official sources, last-checked date, disclaimer, and strict error handling with no guessing or filling in.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the core action, followed by error behavior. The first sentence is somewhat overloaded with the output-field list, but every part is relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a large slug enum, nested inputs, no output schema, and strong safety annotations, the description is complete enough: it explains what the tool returns and how invalid inputs are handled. The schema carries the parameter and slug details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema itself documents slug and inputs thoroughly, including allowed slug values and input value formats. The description adds little parameter-specific meaning beyond saying the calculator runs with the person's values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a precise verb-resource pair: run one GlanceDesk calculator with supplied values and return a tested answer with units, explanation, formula, sources, date, URL, and disclaimer. This clearly distinguishes execution from sibling discovery tools such as search_tools and get_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the agent already has a calculator slug and field values, and it states that invalid or missing values return the calculator's own error. However, it does not explicitly state that search_tools/get_tool should be used first to discover slugs or field ids, and no alternatives are named in the main description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find GlanceDesk calculators and compliance checks by topic, for example "UAE gratuity", "Pakistan salary tax", "loan EMI", "e-invoicing Saudi", "crypto liquidation price", "concrete mix cement bags". Returns each tool's slug, title, one-line description, page URL and which tool runs it.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Most results to return (default 10). | |
| query | No | Words describing what the person wants to work out. Empty lists every tool. | |
| product | No | calculators = GlanceDesk Calculators (money, tax, loans, conversions); jurisdiction = GlanceDesk Jurisdiction (compliance, labour law); crypto = GlanceDesk Crypto (futures, spot, staking, fees, crypto units; user-typed prices, not investment advice); compute = GlanceDesk Compute (engineering estimates for civil, electrical, mechanical and HVAC work; not a design check). Default any. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, so the safety profile is covered. The description adds the concrete return shape (slug, title, one-line description, page URL, owning tool), which matters because there is no output schema, but says nothing about matching behavior, ranking, or how empty/paged results behave.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, with the example list placed where it aids query formulation and the return-value sentence closed out efficiently. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no required parameters, full schema descriptions, and annotations covering read-only/idempotency, the description fills the main remaining gap by describing the return payload since no output schema exists. It stops short of explaining result ordering or transitions to run_calculator, but nothing critical to a correct call is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, and the description earns an increment above that by giving six varied example queries ('UAE gratuity', 'e-invoicing Saudi', 'concrete mix cement bags') that show the expected phrasing granularity for the query parameter. It doesn't address limit or product, but the schema enum already explains those thoroughly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Find GlanceDesk calculators and compliance checks by topic') and the concrete example queries make the discovery scope unambiguous. It doesn't explicitly name the boundary with siblings like get_tool (slug lookup) or run_calculator (execution), so the differentiation is implied by the example queries rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: you search by topic to discover tools, and the returned slug suggests a follow-up get_tool/run_calculator call. However, there is no explicit when-to-use, when-not-to-use, or statement that this is the entry point before run_calculator, leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
run_calculator1 field changedInput schema / properties / slug / enumPrevious value: -[
- "ac-size-calculator",
- "age-calculator",
- "apy-calculator",
- "area-converter",
- "binance-margin-level-calculator",
- "bitcoin-block-reward-calculator",
- "bitcoin-difficulty-adjustment-calculator",
- "bitcoin-mining-profitability-calculator",
- "bitcoin-transaction-fee-calculator",
- "bitcoin-utxo-consolidation-calculator",
- "bmi-calculator",
- "break-even-calculator",
- "brick-calculator",
- "bybit-liquidation-price-calculator",
- "coin-margined-futures-calculator",
- "compound-interest-calculator",
- "concrete-mix-calculator",
- "copy-trading-profit-share-calculator",
- "cross-margin-liquidation-calculator",
- "crypto-address-checker",
- "crypto-arbitrage-spread-calculator",
- "crypto-break-even-calculator",
- "crypto-cost-basis-calculator",
- "crypto-dca-calculator",
- "crypto-liquidation-price-calculator",
- "crypto-percentage-change-calculator",
- "crypto-pnl-calculator",
- "crypto-portfolio-rebalance-calculator",
- "crypto-position-size-calculator",
- "crypto-roi-cagr-calculator",
- "currency-converter",
- "data-storage-converter",
- "date-difference-calculator",
- "defi-health-factor-calculator",
- "discount-calculator",
- "drawdown-recovery-calculator",
- "dual-investment-calculator",
- "electricity-cost-calculator",
- "eth-gas-fee-calculator",
- "ethereum-unit-converter",
- "exchange-liquidation-price-calculator",
- "fitrana-fidya-calculator",
- "fuel-cost-calculator",
- "fuel-economy-converter",
- "funding-fee-calculator",
- "futures-average-entry-price-calculator",
- "futures-basis-calculator",
- "gold-value-calculator",
- "gpa-calculator",
- "grid-trading-calculator",
- "hyperliquid-liquidation-price-calculator",
- "impermanent-loss-calculator",
- "investment-growth-calculator",
- "kva-kw-amps-calculator",
- "length-converter",
- "leverage-margin-calculator",
- "loan-amortization-schedule",
- "loan-emi-calculator",
- "margin-tier-calculator",
- "market-cap-price-calculator",
- "marla-kanal-converter",
- "mortgage-calculator",
- "options-payoff-calculator",
- "p2p-usdt-premium-calculator",
- "pakistan-electricity-bill-calculator",
- "pakistan-federal-pay-calculator",
- "pakistan-freelancer-tax",
- "pakistan-net-to-gross-salary",
- "pakistan-property-tax-calculator",
- "pakistan-salary-tax-calculator",
- "pendle-fixed-yield-calculator",
- "percentage-calculator",
- "power-converter",
- "pressure-converter",
- "profit-margin-calculator",
- "rebar-weight-calculator",
- "remittance-true-cost-checker",
- "risk-reward-calculator",
- "satoshi-converter",
- "saudi-end-of-service-calculator",
- "simple-interest-calculator",
- "solana-transaction-fee-calculator",
- "solana-unit-converter",
- "speed-converter",
- "spot-crypto-profit-calculator",
- "spot-take-profit-ladder-calculator",
- "staking-rewards-calculator",
- "target-price-calculator",
- "temperature-converter",
- "tip-calculator",
- "token-vesting-calculator",
- "trading-fee-calculator",
- "tron-usdt-transfer-fee-calculator",
- "uae-gratuity-calculator",
- "uniswap-v3-liquidity-calculator",
- "vat-calculator",
- "volume-converter",
- "weight-converter",
- "zakat-calculator"
-]New value: +[
+ "ac-size-calculator",
+ "age-calculator",
+ "apy-calculator",
+ "area-converter",
+ "battery-backup-time-calculator",
+ "binance-margin-level-calculator",
+ "bitcoin-block-reward-calculator",
+ "bitcoin-difficulty-adjustment-calculator",
+ "bitcoin-mining-profitability-calculator",
+ "bitcoin-transaction-fee-calculator",
+ "bitcoin-utxo-consolidation-calculator",
+ "bmi-calculator",
+ "break-even-calculator",
+ "brick-calculator",
+ "bybit-liquidation-price-calculator",
+ "coin-margined-futures-calculator",
+ "compound-interest-calculator",
+ "concrete-mix-calculator",
+ "copy-trading-profit-share-calculator",
+ "cross-margin-liquidation-calculator",
+ "crypto-address-checker",
+ "crypto-arbitrage-spread-calculator",
+ "crypto-break-even-calculator",
+ "crypto-cost-basis-calculator",
+ "crypto-dca-calculator",
+ "crypto-liquidation-price-calculator",
+ "crypto-percentage-change-calculator",
+ "crypto-pnl-calculator",
+ "crypto-portfolio-rebalance-calculator",
+ "crypto-position-size-calculator",
+ "crypto-roi-cagr-calculator",
+ "currency-converter",
+ "data-storage-converter",
+ "date-difference-calculator",
+ "decibel-converter",
+ "defi-health-factor-calculator",
+ "discount-calculator",
+ "drawdown-recovery-calculator",
+ "dual-investment-calculator",
+ "electricity-cost-calculator",
+ "eth-gas-fee-calculator",
+ "ethereum-unit-converter",
+ "exchange-liquidation-price-calculator",
+ "fiber-optic-loss-budget-calculator",
+ "fitrana-fidya-calculator",
+ "free-space-path-loss-calculator",
+ "fuel-cost-calculator",
+ "fuel-economy-converter",
+ "funding-fee-calculator",
+ "futures-average-entry-price-calculator",
+ "futures-basis-calculator",
+ "gold-value-calculator",
+ "gpa-calculator",
+ "grid-trading-calculator",
+ "hyperliquid-liquidation-price-calculator",
+ "impermanent-loss-calculator",
+ "investment-growth-calculator",
+ "islamic-inheritance-calculator",
+ "kva-kw-amps-calculator",
+ "length-converter",
+ "leverage-margin-calculator",
+ "loan-amortization-schedule",
+ "loan-emi-calculator",
+ "margin-tier-calculator",
+ "market-cap-price-calculator",
+ "marla-kanal-converter",
+ "mortgage-calculator",
+ "ohms-law-calculator",
+ "options-payoff-calculator",
+ "p2p-usdt-premium-calculator",
+ "pakistan-electricity-bill-calculator",
+ "pakistan-federal-pay-calculator",
+ "pakistan-freelancer-tax",
+ "pakistan-net-to-gross-salary",
+ "pakistan-property-tax-calculator",
+ "pakistan-salary-tax-calculator",
+ "pendle-fixed-yield-calculator",
+ "percentage-calculator",
+ "power-converter",
+ "pressure-converter",
+ "profit-margin-calculator",
+ "pump-power-calculator",
+ "radio-link-budget-calculator",
+ "rebar-weight-calculator",
+ "remittance-true-cost-checker",
+ "risk-reward-calculator",
+ "satoshi-converter",
+ "saudi-end-of-service-calculator",
+ "shannon-channel-capacity-calculator",
+ "simple-interest-calculator",
+ "solana-transaction-fee-calculator",
+ "solana-unit-converter",
+ "speed-converter",
+ "spot-crypto-profit-calculator",
+ "spot-take-profit-ladder-calculator",
+ "staking-rewards-calculator",
+ "target-price-calculator",
+ "temperature-converter",
+ "tip-calculator",
+ "token-vesting-calculator",
+ "trading-fee-calculator",
+ "tron-usdt-transfer-fee-calculator",
+ "uae-gratuity-calculator",
+ "uniswap-v3-liquidity-calculator",
+ "vat-calculator",
+ "voltage-drop-calculator",
+ "volume-converter",
+ "water-tank-capacity-calculator",
+ "weight-converter",
+ "zakat-calculator"
+]breach_notification_deadlinebusiness_filing_deadlinedata_request_deadlineeinvoicing_checkget_toolgulf_final_settlementrun_calculatorsearch_tools90+ pure finance calculators: loans, investing, bonds, options, tax. Stateless, stores nothing.
Find and run trustworthy calculators with clear methods, provenance, and sources.
140+ calculators and data tools — finance, health, science, global comparisons and more.
AI-callable calculators and engineering models with real formulas. No hallucinated math.
Add one secure layer between your agents and this server.
