Geo-Parity

Withholding tax on payments abroad, standard and treaty rate per corridor

withholding_tax

Read-onlyIdempotent

What a company in from keeps back when it pays dividends, interest, royalties or technical fees to a recipient in to: OECD's standard withholding rates for the payer's country and, for the pair, the treaty rate where OECD publishes one, with the saving in points per income type. Direction is the payer's, never reversed; from equal to to is rejected. A pair with no published treaty rate reports the standard rate and says so — that is not the same as no treaty existing, and the treaty figure is the maximum the treaty allows (a residence certificate is usually needed). Without from, ranks all 41 by standard rate on type (dividends default). Standard rates for 41 of 41; treaty rates for about 1,300 payer–recipient pairs within the spine (the Philippines never appears as a payer). Published rates and facts on the dates shown, for information only — not tax, legal or immigration advice; every response says so first.

Input Schema

Name	Required	Description	Default
`to`	No	ISO alpha-2 code of the recipient's country; unlocks the treaty rate.
`from`	No	ISO alpha-2 code of the paying company's country.
`sort`	No		lowest
`type`	No	Income type to rank by when `from` is not given.	dividends
`limit`	No

Output Schema

Name	Required	Description	Default
`ok`	No
`to`	No
`rows`	No
`lines`	No
`treaty`	No
`caveats`	No
`standard`	No
`attribution`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 1, 2026

addedInput schema / examples

Added value: +[
+  {
+    "from": "TH",
+    "to": "GB"
+  }
+]

AddedSep 5, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: direction is the payer's and never reversed, `from`==`to` is rejected, a missing treaty rate reports the standard rate and says so rather than implying no treaty exists, the treaty figure is a maximum, and a residence certificate is usually needed. Coverage stats (41/41 standard, ~1,300 pairs, Philippines never a payer) add real operational context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense paragraph that front-loads the core operation and semantics before the coverage figures and disclaimer. It is long and packed, but nearly every sentence carries distinct information; only the trailing coverage detail feels marginally heavy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema, five parameters, and read-only annotations, the description covers mode selection, edge cases (from==to, missing treaty), defaults, and the mandatory disclaimer. An agent has everything needed to call it correctly and interpret results.

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

Parameters4/5

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

Schema coverage is 60%; the description adds meaning to `to` (unlocks the treaty rate), `from`, and `type` (ranked by when `from` is absent), plus the direction/default behavior. `sort` and `limit` are left to the schema, so it is not fully compensating.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: withholding tax on dividends/interest/royalties/technical fees, returning OECD standard and treaty rates per corridor. It is clearly differentiated from siblings like compare_tax_rates and compare_vat by naming the exact resource and direction semantics.

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

Usage Guidelines4/5

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

Explains the two operating modes explicitly: with `from` it computes the payer-country rate; without `from` it ranks all 41 countries by standard rate on `type` (dividends default). It does not name a sibling alternative or when-not-to-use, 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.

All Geo-Parity tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?