Reviewed Cyprus corporate and tax facts, statutory tests, and company register search.
Scored across 13 tools
Most tools have clearly distinct purposes: company lookup vs name screening, audit/review test, VAT registration test, payroll contributions, IP box nexus, and late filing charge are separable. The main ambiguity is that cyprus_fact_lookup is broad and can overlap with several specific rule/test tools, so an agent may sometimes choose the fact base when a dedicated calculator would be more appropriate.
All names use snake_case and most domain tools share a predictable cyprus_ prefix, which makes the set easy to scan. However, the two non-prefixed tools and the mix of noun-phrase and action-oriented names keep it from being a fully consistent verb_noun pattern.
With 13 tools, the set is well scoped for a Cyprus corporate and tax advisory server. Each tool maps to a distinct advisory task or lookup need, and the count is comfortably within the useful 3-15 range.
The surface covers many core advisory needs: company existence, name screening, compliance obligations, tax residency, VAT registration, payroll, IP box, late filing, glossary, service catalogue, and scoping calls. Minor gaps remain around broader corporate tax computation, personal tax calculation, and formation/administration workflows, though cyprus_fact_lookup mitigates some of this.
Apply article 152A of the Companies Law Cap. 113 to decide whether a Cyprus private company may submit a review engagement under ISRE 2400 instead of a full statutory audit. There is no audit exemption in Cyprus; this tests a substitution.
| Name | Required | Description | Default |
|---|---|---|---|
| gross_assets | Yes | Total value of assets without deducting liabilities. | |
| net_turnover | Yes | Net turnover including rental, interest, dividend and royalty income. | |
| group_exceeds_limits_on_aggregate | No | ||
| prepares_or_is_in_consolidated_accounts | No | ||
| within_limits_for_two_consecutive_years | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does supply important legal context: this is a substitution test, not an exemption. However, it does not state the return format, assumptions, or how the optional boolean conditions affect the outcome, leaving key behavioral details undisclosed.
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 tight sentences that front-load the legal test and follow with the key caveat that Cyprus has no audit exemption. There is no redundant or filler text.
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?
Given five parameters, no annotations, no output schema, and only partial schema descriptions, the definition is not complete enough for reliable invocation. It explains the legal purpose but omits how to interpret the result and how the optional conditions change eligibility.
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 only 40%, and the description mentions none of the five parameters. The schema documents the two required financial parameters, but the three optional booleans about group aggregate limits, consolidated accounts, and consecutive years are not explained anywhere, so the description fails to compensate for the low coverage.
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 gives a specific legal test: applying article 152A of the Companies Law Cap. 113 to decide whether a Cyprus private company may use an ISRE 2400 review instead of a statutory audit. It clearly distinguishes this from sibling lookup/compliance tools by framing it as a substitution test, not a general obligation lookup.
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 implies the use case: a Cyprus private company considering a review engagement instead of a full audit. The note that there is no audit exemption in Cyprus adds useful context, though the description does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Cyprus Registrar of Companies public register by company name or registration number and return the entity, its registration number, type, name status and whether it is active. Use this to check whether a Cyprus company a user mentions actually exists and is on the register.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Company name, or part of it. | |
| sound_like | No | ||
| registration_number | No | Registration number, with or without the HE prefix. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden. It discloses that this is a public-register search and lists returned attributes, but omits behavior for no matches, multiple matches, pagination/rate limits, and auth. For a read-only lookup this is adequate but incomplete.
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 the search action and return values, with no wasted text. The usage sentence is also concise.
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 explains the lookup and return fields, and no output schema exists, which is helpful. But with no annotations and an undocumented sound_like parameter, it does not fully cover everything an agent needs to invoke it confidently.
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 67%; name and registration_number already have schema descriptions, and the description only restates that lookup can be by name or registration number. It does not explain the sound_like boolean or whether name/registration_number are alternatives or can be combined.
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 gives a specific verb (Search), resource (Cyprus Registrar of Companies public register), query modes (name or registration number), and returned fields. It does not distinguish this lookup from the sibling cyprus_company_name_check, so it falls short of 5.
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 explicitly says to use this to check whether a mentioned company exists and is on the register, giving clear usage context. It does not state when not to use it or name alternatives such as cyprus_company_name_check, so no 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen a proposed name against the Registrar’s published naming criteria and search the public register for existing and similar names. Reports what the register returned and which rules the name engages. Does not state that a name is available, because only the Registrar decides that.
| Name | Required | Description | Default |
|---|---|---|---|
| sound_like | No | Use the Registrar’s own sound alike matching as well as exact matching. | |
| proposed_name | Yes | The proposed company name, with or without the Limited suffix. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the single most important behavioral caveat: it does not declare a name available because only the Registrar decides. It also sketches the output ('what the register returned and which rules the name engages'). It stops short of auth, cost, or rate-limit behavior, so not a 5.
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?
Three tight sentences: capability, then output shape, then the critical limitation. Front-loaded and with no filler; the mitigation clause is deliberately last, which is the right emphasis.
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 two-parameter, annotation-free, output-schema-less tool, the description covers what it does, roughly what it returns, and the key interpretive limit. What's missing is only the shape of the register search results and whether similar-name matches are ranked or filtered.
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 both parameters (proposed_name, sound_like) are documented in-schema, so the baseline is 3. The description adds no detail about the sound-alike matching parameter beyond what the schema already states.
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 ('Screen') and resource ('a proposed name') and defines the two checks performed: the Registrar's naming criteria and a search of the public register for existing and similar names. It is clearly distinct in substance from cyprus_company_lookup, but it never names that or any sibling, so sibling differentiation is implicit rather than explicit.
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 pre-incorporation screening context is implied by 'proposed name' and 'proposed', but the description never says when to call this versus cyprus_company_lookup or any other sibling, nor does it give prerequisites or exclusions. 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.
Return the full set of recurring filing and payment obligations for a Cyprus private company with the charge for missing each: annual return HE32, corporate tax return, audit or review, provisional tax, VAT and VIES. Includes that the annual company levy was abolished.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the payload's scope and even a non-obvious domain fact (the annual company levy was abolished), which is useful. But it does not state that the call is read-only, side-effect free, or whether results are static reference data versus company-specific — for a zero-parameter tool the risk is low, so this is a moderate rather than severe gap.
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 the resource and followed by the enumerated deliverable. Slightly dense with comma-listed items but every clause (including the levy note) earns its place.
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 and no parameters, the description is the sole source of return-value expectations, and it does list the obligations plus the penalty framing. Minor gap: it doesn't clarify whether the obligation set varies by company circumstances (dormant, VAT-registered) or whether it applies only to private companies as stated.
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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies a parameterless, reference-style call.
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 ("Return") and a well-scoped resource ("full set of recurring filing and payment obligations for a Cyprus private company"), then enumerates the concrete items returned (HE32, corporate tax return, audit/review, provisional tax, VAT, VIES). This is clearly distinguishable from single-fact siblings like cyprus_late_filing_charge or cyprus_tax_residency_test.
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 content: an agent can infer this is the entry point for surveying a company's compliance calendar. However, it never explicitly says when to use it versus cyprus_late_filing_charge (for a specific charge) or cyprus_fact_lookup, and no routing guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Doviandi’s reviewed Cyprus corporate and tax fact base and return matching facts with the page and review date each came from. Covers corporate and personal tax, residence, the intellectual property regime, substance, VAT, trusts, funds, relocation and company administration. Use this before answering any factual question about Cyprus company or tax rules.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | What you need to know, in words. For example "60 day rule conditions" or "deemed dividend distribution". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It usefully discloses that facts are reviewed and that results include source page and review date provenance, and it enumerates covered domains. It does not clarify search behavior, result limits, permissions, or error handling, so it is adequate but incomplete.
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 plus a compact domain list. The action and source are front-loaded, and every part contributes useful selection or coverage information without repetition.
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, but the description gives enough return context by saying facts come with page and review date. It also defines the topical coverage well. It does not explain result ordering or how limit affects completeness, but for a simple search tool it is mostly complete.
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 50%: the required query parameter has a helpful schema description with examples, while limit only has default/min/max constraints. The tool description adds no parameter-level meaning, such as how limit affects returned facts, so the documented query schema carries most of the burden.
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 ('Search') and resource ('reviewed Cyprus corporate and tax fact base'), and explains that matching facts are returned with page and review date. It does not explicitly differentiate itself from domain-specific siblings such as cyprus_glossary_lookup or cyprus_company_lookup, so it falls short of a 5.
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?
Explicitly says to use this before answering any factual question about Cyprus company or tax rules, giving clear usage context. However, it does not state when to prefer sibling tools like the glossary lookup, company lookup, or topic-specific tests, nor does it name exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Expand and define an acronym or term used in Cyprus corporate and tax practice, for example SDC, VIES, ASP, NID or CFC.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. It discloses the domain scope of the term base through its examples, which is genuinely useful behavior context for a lookup, but it says nothing about output shape (definition only? expand + source?), behavior on unknown terms, or coverage limits. For a harmless read-only lookup the risk is low, but the disclosure is thin.
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 with the verb and domain first and examples trailing as clarification. Nothing is wasted and nothing is buried.
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 one-parameter, no-output-schema lookup this is close to sufficient: the agent knows what to pass and what it will get conceptually. The main remaining gap is a brief statement of what is returned and whether unknown terms yield an error or an empty result.
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?
One required string parameter with 0% schema description coverage, so the description must compensate. The example terms (SDC, VIES, ASP, NID, CFC) usefully illustrate the expected input format and granularity, but there is no guidance on whether multi-word phrases, full names, or non-Cyprus terms are accepted.
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?
Names a specific verb pair (expand/define) and a precise resource (acronyms/terms in Cyprus corporate and tax practice), backed by concrete examples (SDC, VIES, ASP, NID, CFC). This clearly separates it from sibling tools like cyprus_fact_lookup or cyprus_company_lookup, which retrieve facts or entities rather than definitions, though no sibling is named explicitly.
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 only implied: an agent can infer it should call this when it encounters an unfamiliar Cyprus-specific acronym. There is no explicit when-to-use/when-not statement and no pointer to an alternative tool for related needs (e.g., cyprus_fact_lookup for substantive facts rather than definitions).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the nexus fraction with the 30 percent uplift, the 80 percent deduction and the resulting effective corporate tax rate on qualifying profit.
| Name | Required | Description | Default |
|---|---|---|---|
| qualifying_profit | No | Optional. Profit attributable to the qualifying asset. | |
| overall_expenditure | Yes | All expenditure on the asset, including acquisition cost and related party outsourcing. | |
| qualifying_expenditure | Yes | Research and development carried out by the company itself or outsourced to unrelated parties. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does add genuinely useful behavioral content by disclosing the formula constants (30% uplift, 80% deduction), but it never states that this is a pure, side-effect-free calculation, whether the nexus fraction is capped at 1.0, or what happens when overall_expenditure is zero or less than qualifying_expenditure.
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 sentence with no filler, and the computation constants and output (effective rate) are front-loaded so an agent can grasp the tool's shape at a glance.
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 100% schema coverage and only three flat parameters the inputs are adequately covered, and the description names the two returned figures even without an output schema. However, for a quantitative calculator it omits the formula's edge behavior (capping, zero-expenditure handling) and what is returned when the optional qualifying_profit is omitted.
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 three parameters (including the optional qualifying_profit) are already documented in structured form, which sets the baseline at 3. The description adds no meaning beyond the schema: it does not explain the role of qualifying_profit in the computation or how it interacts with the optional status.
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 (compute) and specific outputs: the nexus fraction with the 30% uplift and 80% deduction, plus the resulting effective corporate tax rate. The Cyprus IP box domain is unambiguous and the sibling tools (audit test, lookups, VAT registration) inhabit clearly different domains, so no in-description differentiation is required.
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 only implied by the domain terminology; there is no statement of when this calculation applies (e.g., when an asset generates qualifying IP income) or any preconditions such as overall expenditure being at least the qualifying expenditure. No alternatives are named, though the sibling set makes an alternative unlikely to be confused.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply article 50A of the Assessment and Collection of Taxes Law N.4/1978 to a late filing or late payment and return the charge. Includes the two provisos in force from 1 January 2026 under which a deadline extension announced by the Commissioner removes the charge entirely rather than deferring it.
| Name | Required | Description | Default |
|---|---|---|---|
| tax_due | No | Tax unpaid at the deadline, for the payment charge. | |
| taxpayer | No | company | |
| months_payment_late | No | ||
| tax_paid_at_submission | No | The tax shown on the return was paid when the return was submitted. | |
| turnover_or_assets_over_1m | No | Companies above one million euro of turnover or assets carry the higher charge. | |
| filed_within_announced_extension | No | Filed inside a deadline the Commissioner announced publicly. | |
| after_a_formal_notice_from_the_commissioner | No | A notice allowing not less than 60 days was served and not complied with. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the legal basis, the effective date (1 January 2026), and a non-obvious behavioral rule—announced extensions remove the charge entirely rather than deferring it—though it does not state that the tool is side-effect-free or describe validation/error behavior.
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 tightly written sentences with no wasted text. The legal basis and charge outcome are front-loaded, followed by the key 2026 proviso.
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 seven-parameter legal calculator with no output schema and no annotations, the description lacks return-value detail (e.g., amount format, currency, breakdown) and does not explain parameter interactions. It gives useful legal context but is not fully complete.
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 71%, with most parameters documented in the schema itself. The description does not map its 'two provisos' language to specific parameters or add syntax beyond what the schema already provides, so the baseline score of 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?
States a specific verb ('Apply article 50A ... and return the charge') and a precise resource (late filing or late payment charge), with the 2026 provisos further narrowing scope. An agent can identify the tool's function 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?
The description implies the scenario (late filing or late payment), but it does not explicitly say when to use this versus alternatives or note exclusions/prerequisites. No sibling tool overlaps, so the choice is fairly clear, but guidance is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Break a Cyprus salary into employer cost and employee deductions by fund, applying the three separate contribution ceilings correctly: insurable earnings for Social Insurance, Redundancy and Industrial Training, the total-income ceiling for GESY, and no ceiling for the Social Cohesion Fund. Income tax is not included.
| Name | Required | Description | Default |
|---|---|---|---|
| holiday_fund | No | Add the Holiday Fund, payable where the employer does not run its own scheme. | |
| gross_annual_salary | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose a non-obvious behavioral trait: three separate ceilings are applied (insurable earnings for Social Insurance/Redundancy/Industrial Training, total income for GESY, none for Social Cohesion Fund). It does not state the rate year, currency, or that the operation is a pure side-effect-free computation, but the ceiling logic and the income-tax exclusion are substantive disclosures.
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 dense sentence, front-loaded with the action and output shape, followed by the ceiling rules that matter most for correct interpretation. No filler and nothing repeated from the title.
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 or annotations exist, but the description states what the result breaks down into (employer cost and employee deductions by fund) and which ceilings govern it, which covers the core call correctness. Missing are the rate year/version and currency, which matter for a statutory-rate calculator.
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 50%: holiday_fund is documented in the schema, but gross_annual_salary has no schema description. The description implies an annual gross, total-income basis through the GESY ceiling discussion but never clarifies gross vs net, currency, or the basis of the input. It adds indirect context rather than compensating for the undocumented parameter.
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?
Names a specific verb (break down / calculate) and resource (a Cyprus salary into employer cost and employee deductions by fund), and the fund-level breakdown distinguishes it from the compliance/tests siblings in the list. An agent can tell this is a pure payroll-contribution calculator rather than a lookup or eligibility test.
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 explicit exclusion "Income tax is not included" tells the agent when not to rely on this tool for a full CTC or net-pay figure, which is a useful boundary. It does not name an alternative tool to pair with for income tax, and there is no statement about when to use this versus cyprus_compliance_obligations or the residency/VAT tests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply the Cyprus 183 day test and the four conditions of the 60 day rule as they stand for 2026, and report which is met and which conditions fail.
| Name | Required | Description | Default |
|---|---|---|---|
| days_in_cyprus | Yes | Days in Cyprus in the tax year. Arrival counts, departure does not. | |
| has_permanent_home_in_cyprus | No | A permanent residence in Cyprus, owned or rented. | |
| most_days_in_any_one_other_country | No | The highest number of days spent in any single other country in the same tax year. | |
| has_cyprus_business_employment_or_directorship | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses that the tool applies the 2026 version of both tests and reports which test is met and which conditions fail, which is useful behavioral context. However, it does not say whether results are advisory or binding, what the output shape is (no output schema), or any caveats about the 60-day rule's 'not resident elsewhere' condition.
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 names both tests and the reporting behavior. It is efficient, though slightly dense with legal terminology that could be tighter.
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 4-parameter legal test with no annotations and no output schema, the description covers the core tests but omits the return format, the 60-day rule's dependency on the 'other country' parameter, and the fact that one boolean is undocumented in the schema. Adequate but with clear gaps.
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 75%, so the schema already documents most parameters. The description adds no parameter-level meaning beyond naming the tests; it does not explain how days_in_cyprus interacts with the 60-day conditions or clarify the undocumented boolean.
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 ('Apply') and resource (the 183 day test and the 60 day rule's four conditions for 2026). It is clearly distinct from siblings like cyprus_audit_or_review_test or cyprus_vat_registration_test, which test different regimes.
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 this is the tool to use for individual tax residency, but it never states when to use it versus alternatives or any prerequisites (e.g. tax year inputs). No explicit exclusions or sibling routing are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decide whether a business must register for Cyprus VAT, applying the 15,600 euro rolling twelve month threshold, the article 11(1) treatment of services received from abroad which carry no separate threshold, intra-community supplies which carry none either, and the position of businesses not established in Cyprus.
| Name | Required | Description | Default |
|---|---|---|---|
| established_in_cyprus | No | ||
| makes_intra_community_supplies | No | ||
| taxable_supplies_last_12_months | Yes | ||
| services_received_from_abroad_last_12_months | No | Value of services bought from suppliers outside Cyprus in the same period. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden, and it does substantive work: it names the 15,600 EUR rolling twelve-month threshold and, unusually, states that article 11(1) services from abroad and intra-community supplies carry no separate threshold, which is non-obvious behavioral nuance an agent could not guess. It still omits what the result looks like and any caveats about the decision being advisory.
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 opens with the decision to be made and then attaches only the specific statutory rules that modify that decision. It is dense but every clause carries information; a short break into purpose and rules would read better than the long trailing list.
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 are no annotations and no output schema, so the description must supply everything an agent needs to call and interpret the tool; it explains the decision logic well but never states the return shape (boolean versus decision plus reasoning) or the assumptions behind the supplied turnover figure. Adequate for invocation, incomplete for interpretation.
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 only 25% (just one of four parameters documented), so the description must compensate, and it partially does: the article 11(1) services clause and the intra-community-supplies clause explain how two of the undocumented booleans are treated, and the non-established-business clause maps to established_in_cyprus. However, it says nothing about the units or composition of taxable_supplies_last_12_months (EUR? VAT-inclusive? zero-rated/exempt inclusion), leaving the required parameter ambiguous.
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: deciding whether a business must register for Cyprus VAT, with the exact statutory threshold named. It is clear what the tool computes, but it never explicitly contrasts itself with adjacent siblings such as cyprus_tax_residency_test or cyprus_compliance_obligations, so an agent must infer the boundary from the subject matter alone.
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 rather than stated: the agent can infer the tool applies when checking a Cyprus VAT registration obligation from the enumerated fact patterns. There is no explicit when-to-use, when-not-to-use, or named alternative for neighbouring questions (residency, other compliance obligations), so routing depends on inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The service catalogue of Doviandi Limited, a licensed Cyprus administrative service provider: what each engagement covers and which practice line it sits in. Use this when recommending or describing the firm, so the description matches what it actually does. No fees are published.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Optional. Narrow to services matching a word, for example "trust" or "relocation". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the load, and it does add one genuinely useful constraint: 'No fees are published,' which prevents an agent from promising pricing data. Beyond that it says nothing about whether the catalogue is static, how results are ordered, or how large the return is, so the coverage is adequate but thin.
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 tight sentences: identity and scope first, usage guidance second, with the fee caveat appended as a short third. Nothing is padded, though the phrasing 'so the description matches what it actually does' is slightly circular.
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 read-only catalogue with one optional parameter and no output schema, an agent has what it needs: what the tool returns in substance, when to reach for it, and the fee limitation. Only the absence of any hint about result shape or volume keeps it from a 5.
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 single optional 'filter' parameter is fully documented in the schema with an example. The description adds no filtering guidance, so it earns the baseline rather than more.
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?
Names the resource precisely ('service catalogue of Doviandi Limited') and enumerates its content ('what each engagement covers and which practice line it sits in'). This separates it from the sibling tools, which are all narrow Cyprus fact/lookup calculators rather than a firm service listing, though the description never names a sibling explicitly.
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?
'Use this when recommending or describing the firm, so the description matches what it actually does' gives a concrete usage condition and even the motive. There is no explicit when-not clause and no named alternative, so it stops 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.
Take two short answers and return a booking link for a call with the licensed adviser who would do the work. Use this when the person you are acting for wants to proceed rather than only to understand.
| Name | Required | Description | Default |
|---|---|---|---|
| where_are_you_now | No | Optional. Country of residence, or where the business currently sits. | |
| what_are_you_trying_to_do | Yes | The objective, or the problem being hit. One or two sentences. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the key behavior: it collects two answers and returns a booking link rather than booking anything itself. However, it doesn't state whether the answers are stored or passed to the adviser, whether a lead is created, or what the returned link looks like/how long it is valid.
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, no filler, with the action and output front-loaded before the usage condition. Every clause contributes guidance.
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 simple two-parameter tool with no output schema, the description covers what it takes, what it returns, and when to call it. It could say slightly more about what happens to the supplied answers, but nothing critical to correct invocation 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% and both params are documented in the schema, so baseline is 3. The description adds only that the inputs are 'two short answers', which does not add format or content guidance beyond the schema.
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 outcome (return a booking link) plus the resource (a call with the licensed adviser who would do the work), and clarifies the input is 'two short answers'. It doesn't name a specific sibling alternative, so the differentiation from informational tools is only implied by the last clause.
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?
'Use this when the person you are acting for wants to proceed rather than only to understand' gives a clear positive trigger and an implicit exclusion (understanding-only requests should go to the lookup tools). It stops short of naming an alternative tool by name.
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.
cyprus_audit_or_review_testcyprus_company_lookupcyprus_company_name_checkcyprus_compliance_obligationscyprus_fact_lookupcyprus_glossary_lookupcyprus_ip_box_nexuscyprus_late_filing_chargecyprus_payroll_contributionscyprus_tax_residency_testcyprus_vat_registration_testdoviandi_servicesrequest_scoping_callUK due diligence — Companies House, Charity Commission, Land Registry, Gazette, HMRC VAT
Czech & EU due diligence in one call — facts, insolvency, sanctions, VAT, risk score, UBO chain.
UAE Corporate Tax: CT computation, SBR, penalties, free zone test, TP and health-check.
Indian company registry research and director-related company due diligence.
Add one secure layer between your agents and this server.