UpGrowth: business data for Algeria, Tunisia and Morocco

Compute the deadline to repatriate export receipts

export_repatriation_deadline

Read-only

Compute the last day on which an Algerian exporter must repatriate the receipts of a non-hydrocarbon export, under règlement n° 26-02 of 23 July 2026 (JO 2026 no. 58, page 27), article 2, which rewrites article 61 of règlement n° 07-01 of 3 February 2007. The contract may be cash or credit. The receipts are repatriated within 120 days at most from the shipment date (goods) or the completion date (services). When the payment term granted to the non-resident client and written in the commercial contract is above 120 days, up to 180 days at most, the export must first be backed by an export credit insurance taken with the national body for it: the deadline is then the start date plus the term, and export_credit_insurance_required is true. A term above 180 days is refused (refused true, no deadline): 180 days is the maximum. In every case the receipts are repatriated on the day the non-resident client pays: with payment_date, payment.repatriation_day is that day and the answer says whether it falls before, on or after the deadline. Returns days_used, last_repatriation_date, the reminders and the legal basis (act, article, JO issue and page, links) in the language asked. Calendar days, no weekend or holiday shift; it does not check that the contract is outside hydrocarbons or which shipments the rule covers. An estimate from a public text, not legal advice. Free tier allowed. Algeria only (country DZ); other countries return country_not_available.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "kind": "<kind>",
      "start_date": "<start_date>"
    },
    "name": "export_repatriation_deadline"
  }
}

Input Schema

Name	Required	Description	Default
`kind`	Yes	goods (the start date is the shipment date) or services (the start date is the completion date).
`lang`	No	Language of the labels, notes and attribution text in the answer: fr (French, the default), ar (Arabic) or en (English).	fr
`country`	No	Country of the data, an ISO 3166-1 alpha-2 code in any letter case: DZ for Algeria, the default, TN for Tunisia or MA for Morocco. Only live countries answer: list_countries shows them and their datasets. Any other country, or a dataset the country does not have (for example the activity nomenclature for Morocco), returns country_not_available. Without an API key only DZ answers: TN and MA return key_required.	DZ
`start_date`	Yes	The shipment date for goods or the completion date for services, written YYYY-MM-DD, for example 2026-11-15.
`payment_date`	No	Optional: the day the non-resident client paid, YYYY-MM-DD. The receipts are repatriated on that day.
`payment_term_days`	No	Optional: the payment term in days written in the commercial contract. Left out or up to 120: the deadline is 120 days. From 121 to 180: export credit insurance is required first and the deadline is the start date plus the term. Above 180: refused.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint, but the description adds the whole decision tree an agent needs: insurance is required for terms of 121–180 days, terms above 180 are refused with no deadline, payment_date triggers a comparison of the actual repatriation day against the deadline, and calendar days apply with no holiday shift. It also discloses the free-tier allowance and the 'not legal advice' caveat.

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

Conciseness4/5

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

The purpose is front-loaded in the first clause and the branching logic is ordered sensibly (120 days → 121–180 → above 180 → payment case). It is nevertheless a dense single block of roughly 200 words, with the statutory citation chain and repeated restatement of the 120/180 limits adding some bulk.

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?

There is no output schema, so the description carries the burden of describing returns, and it does: days_used, last_repatriation_date, reminders, and the legal basis with act, article, JO issue, page and links in the requested language. For a computation tool with six parameters and conditional branches, nothing an agent needs in order to call it correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter is already documented, and the description largely restates those definitions (payment_term_days thresholds, payment_date meaning) rather than extending them. It does add the causal link that the deadline equals start date plus the contractual term in the insurance branch, but that is the only real increment beyond the schema.

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?

The opening sentence states a specific verb and resource — computing the last repatriation day for a non-hydrocarbon export — and anchors it to the exact legal instrument (règlement n° 26-02, art. 2, rewriting art. 61 of règlement n° 07-01). No sibling tool covers repatriation deadlines, and the description makes the scope unmistakable (Algeria only, goods or services).

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?

It gives concrete usage conditions: cash or credit contracts, goods vs services start dates, the 120/180-day branches, and the 180-day ceiling that triggers a refusal. It also states exclusions — the tool does not verify that the contract is outside hydrocarbons or which shipments the rule covers — and that non-DZ countries return country_not_available. It stops short of explicitly routing the agent to a named sibling for those cases.

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

All UpGrowth: business data for Algeria, Tunisia and Morocco 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.