Morocco communes

Economic establishments

get_economy

Read-onlyIdempotent

HCP's 2024 count of economic establishments for Morocco or any région, province or préfecture, cercle, commune or arrondissement: how many establishments were mapped, how many are public services, how many are associations in premises of their own, how many are businesses, and how many permanent jobs those businesses hold. The businesses are split three ways, each covering all of them: by sector (industry, construction, commerce, services), by how many people work there (1, 2-3, 4-9, 10-49, 50 and over), and by when they were founded (before 1956 through 2020 and later). The weekly souks in use are counted beside them and are not part of the total.

Reading them: every figure is a count, taken during the census by field teams who mapped each establishment. Farming is out, the workbook counts every sector but agriculture, and the jobs are the permanent ones.

Ranking and comparing: to order communes by one of these, call list_communes with sort set to its path, such as economy.establishments.jobs, or by one of the 3 it works out from them: economy.per1000.establishments, economy.per1000.jobs, economy.perBusiness.jobs. To compare the régions, the provinces or the arrondissements, give level without a unit and get them all in one call.

Casablanca and the 5 other cities divided into arrondissements are counted by arrondissement, so their figures are the sum of those, marked basis: arrondissement_sum. Say so when you report one.

Input Schema

TableJSON Schema

Name	Required	Description
`unit`	No	A région, province or préfecture, cercle, commune or arrondissement, by code or slug. Morocco as a whole when left out.
`level`	No	With a unit, the level it's at, where a name is shared: Tiznit is a commune and a province, and a name alone means the commune. Without a unit, region, province or arrondissement gives every one of that level in one call.
`topics`	No	Only these topics. Every topic when left out.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`results`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 21, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the readOnly and idempotent annotations, the description discloses important behaviors: souks are counted separately and excluded from the total, agriculture is excluded, jobs are permanent, and cities with arrondissements are reported as arrondissement sums with basis: arrondissement_sum. These are exactly the non-obvious behaviors an agent needs before invoking the tool.

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

Conciseness5/5

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

The description is long but every section earns its place: a clear inventory of counts, a 'Reading them' caveat block, a 'Ranking and comparing' routing block, and a specific arrondissement_sum warning. It is front-loaded with the core count definition and uses compact, structured paragraphs rather than repetition.

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 read-only data retrieval tool with an output schema, the description covers all necessary context: granularity, exclusions, parameter behavior, comparison usage, and output semantics for arrondissement cities. An agent has enough information to select the tool, call it correctly, and interpret the result.

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 100%, but the description still adds meaning: it explains that a bare name defaults to the commune (e.g., Tiznit), that level without a unit returns every unit of that level, and that business splits correspond to sector, size, and founding period. This exceeds the baseline for fully covered 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 description opens with a precise verb and resource: 'HCP's 2024 count of economic establishments for Morocco or any région, province or préfecture, cercle, commune or arrondissement.' It names the exact metrics returned (establishments, public services, associations, businesses, permanent jobs) and clearly separates this from siblings like get_housing and list_communes.

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?

The description gives explicit routing guidance: 'To order communes by one of these, call list_communes with sort set to its path' and 'To compare the régions, the provinces or the arrondissements, give level without a unit and get them all in one call.' This tells the agent when to use an alternative tool and when to use this tool differently.

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

All Morocco communes 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.