Nissab-Zakat: a public data service built for agents as well as crawlers

The nisab is the wealth threshold above which zakat becomes due. It is defined in terms of gold (85g) and silver (595g), which means answering “what is it today?” requires live metal prices, an FX rate, and a decision about which of the two thresholds to use.

Nissab-Zakat answers that question in 11 languages and roughly 150 currencies, for free, with no account. It is a public-interest reference rather than a business — which is precisely what made the interesting design decision available.

The constraint

A site like this has two audiences, and only one of them was ever designed for.

The first is a person with a browser. The second is a machine: a search crawler, an LLM answering a question about zakat, or an agent that needs today’s threshold as a number it can compute with. For that second audience the usual answer is “scrape the HTML and hope” — brittle for them, and lossy for us, because a scraped page carries none of the provenance that makes a religious finance figure trustworthy.

Since there was no commercial reason to hoard the data, we could design for the machine audience directly.

The decision

Treat machine consumers as a first-class surface with its own contract, and make that surface discoverable rather than documented in a PDF nobody finds.

Concretely, the site ships:

• An MCP server. Stateless JSON-RPC 2.0 over Streamable HTTP, negotiating several protocol revisions, exposing a tool that returns the current thresholds in any ISO-4217 currency. An agent can ask for today’s nisab in Malaysian ringgit and get a typed answer with its provenance, rather than a paragraph of HTML.
• /.well-known/api-catalog — an RFC 9727 linkset, so a machine can find the API without being told where it is.
• /.well-known/mcp.json — a server card, so an MCP client can discover and connect on its own.
• Link headers on responses advertising the sitemap, the catalogue and llms.txt, for consumers that never read the HTML body at all.
• llms.txt and llms-full.txt, and a robots.txt that names the major AI crawlers explicitly and declares content signals rather than leaving intent ambiguous.
• A public JSON API and an embeddable widget, so a mosque or charity site can show the live threshold without rebuilding any of this.

What sits underneath

None of that is worth anything if the numbers are wrong or stale, so the data path is deliberately conservative:

• Contracts and adapters. Metals pricing, FX and geo-to-currency each sit behind an interface with a swappable implementation and typed DTOs. Providers in this space change terms and go dark; none of them are allowed to leak into the domain.
• Cached with an explicit refresh path, on a schedule — FX twice daily, metals daily.
• Freshness is monitored, not assumed. A daily check alerts when data is older than it should be, and the service raises rather than silently rendering a zero. A zakat threshold that is quietly wrong is worse than one that is honestly unavailable.
• Bounded retention. Price history is pruned on a rolling window rather than growing without limit.

SEO and localisation as engineering

The other half of the work is being findable by the human audience, which for a reference site means being genuinely multilingual rather than machine-translated:

• 11 locales, with Accept-Language q-weight negotiation and a Vary header so caching stays correct per language.
• Programmatic landing pages for the common currency queries, in every locale, each with structured data rather than a thin templated page.
• Server-rendered throughout — Livewire and Blade, no JavaScript framework. For a page whose job is to show one number quickly on a slow connection, that is the right trade.
• Cache headers with stale-while-revalidate, a dependency-free inline SVG trend chart, and a service worker with an offline page.

What it cost

The agent-native surface is genuinely more work than a REST endpoint and a link to it: several well-known documents to keep correct, a protocol to track as it revises, and a test suite that has to cover discovery and version negotiation rather than just responses. The specifications are also young enough that some of this will need revisiting.

It is also, so far, a bet. The audience of agents that discover a service this way is real but early. We took it because the marginal cost on a project with no commercial pressure was low, and because the alternative — being scraped badly — was the default outcome anyway.