Skip to main content
Glama

UpGrowth: business data for Algeria, Tunisia and Morocco

by io.github.Z4KARY
OverviewDiscussionsAdmin

Get the social contributions of a country

get_social_contributions
Read-only

Get the social contributions and payroll levies in a country in 2026, each with its base, its legal source and the official page it was read on. Algeria (DZ, the default country): the CNAS social security contribution on salaries (34.5 %: 25 % employer, 9 % employee and 0.5 % social works fund, with its split by branch; unemployment insurance and early retirement are branches inside that rate, not separate contributions), five special categories of workers (home workers, people employed by private individuals, artists and authors, parking attendants, fishing crews), and the CASNOS contribution of the self-employed with its rate, its base, its floor and ceiling (rule of executive decree 26-257, published 23 July 2026) and the auto-entrepreneur flat option. The Algerian list is not complete: the other categories of decree 85-34, journalists paid by the task, professional sports clubs and the CACOBATPH are not in it (see the note of cnas_general_regime), so never say a contribution does not exist because it is missing here: search the Journal officiel. Tunisia (TN): the social security (CNSS) contribution with its employer and employee shares, the work accident range, the complementary pension regime and the payroll levies (vocational training tax TFP and housing fund contribution FOPROLOS). Morocco (MA): the CNSS contributions (family allowances, short-term and long-term social benefits with their salary ceiling), the compulsory health insurance (AMO) and the vocational training tax (TFP), with the employer and employee shares. For an Algerian estimate use calculate_casnos and calculate_ifu. Tunisia and Morocco need an API key.

Input Schema

NameRequiredDescriptionDefault
langNoLanguage of the labels, notes and attribution text in the answer: fr (French, the default), ar (Arabic) or en (English).fr
countryNoCountry 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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / country / description
      Previous value: -"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, returns country_not_available."New value: +"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."
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only supply readOnlyHint and openWorldHint, so the description carries the real behavioral load and does so: it discloses the API-key gate for TN/MA, that the Algerian list is incomplete and which categories are excluded, and that missing entries must not be read as non-existence. That auth constraint plus data-coverage caveat is exactly the beyond-annotations context an agent needs.

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

Conciseness3/5

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

The purpose is front-loaded and the closing sentences carry the routing and auth guidance, but the middle is a dense per-country enumeration whose internal rate detail (34.5 % split, decree references) reads more like output documentation than definition. Effective but bloated for a two-parameter lookup tool.

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?

For a multi-jurisdiction reference tool with no output schema, the description is complete: it summarizes the shape of the answer, names supported countries, flags the incompleteness of the Algerian dataset, and points to the estimate tools. An agent has everything needed to call it correctly and interpret gaps.

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 coverage is 100% and both parameters (lang, country) are fully documented in the schema with defaults, enum and the country_not_available/key_required behavior. The description reinforces the DZ default and names the supported countries, but adds little the schema does not already state, so baseline 3 is right.

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 and resource ('Get the social contributions and payroll levies in a country in 2026') and enumerates exactly what is returned per jurisdiction (base, legal source, official page read on). An agent can distinguish this revenue/levy reference tool from calculate_casnos or get_tax_rates without opening any schema.

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

Usage Guidelines5/5

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

Explicitly routes usage: 'For an Algerian estimate use calculate_casnos and calculate_ifu' names the alternatives and the condition, and it states 'Tunisia and Morocco need an API key'. It also warns when not to conclude absence ('never say a contribution does not exist because it is missing here: search the Journal officiel'), which is unusually actionable routing guidance.

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 toolsInspect
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