Morocco communes

List communes

list_communes

Read-onlyIdempotent

Communes filtered by région, province or préfecture, cercle, type or population, 50 to a page, in code order or sorted by name, population, change since 2014, density, area, any census indicator or any establishment count. Filters combine; each unit can be given by code or slug. With no filter it lists every commune, so sort: "-population" alone gives the largest in the country.

Input Schema

TableJSON Schema

Name	Required	Description
`page`	No	Page number, from 1.
`sort`	No	A field to order by: code, name, population, change, density, area, or a census indicator by its path, such as labour.unemploymentRate or amenities.runningWater, as get_indicators names them. Put 2014. before the path for the 2014 figure, or change. for how far it moved since, as in change.illiteracy.rate10Plus. An establishment count goes under economy., as in economy.establishments.jobs or economy.sector.commerce, as get_economy names them. A count on its own ranks the biggest places first, so 3 figures worked out from 2 counts rank by size of place rather than size: economy.per1000.establishments, economy.per1000.jobs and economy.perBusiness.jobs. A leading minus puts the largest first. Code order when left out.
`type`	No	Urban or rural communes only.
`cercle`	No	A cercle, by code or slug.
`region`	No	A région, by code or slug.
`province`	No	A province or préfecture, by code or slug.
`max_population`	No	Only communes with at most this many people in 2024.
`min_population`	No	Only communes with at least this many people in 2024.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`page`	Yes
`total`	Yes
`communes`	Yes
`total_pages`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 21, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations indicate readOnlyHint and idempotentHint true, so it's a safe read operation. The description adds pagination behavior (50 per page), sorting defaults, and combination of filters, which are not in annotations. No contradiction.

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 front-loaded with the core purpose, and every sentence adds necessary detail about sorting and filtering options. No fluff; it's dense but organized.

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 high complexity (8 params, complex sort syntax), the description covers all essential usage patterns. Output schema exists, so return details are provided. Complete for agent to select and invoke correctly.

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%, so parameters are documented in schema. But description adds value by explaining how sort works with indicator paths (e.g., labour.unemploymentRate, change. prefix, per1000 counts) and that filters combine. This goes beyond 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 clearly states it lists communes with various filters, sorting, and pagination. It distinguishes from siblings by mentioning sorting by indicators and establishment counts, which are unique to this tool. The verb 'list' and resource 'communes' are specific.

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?

It explicitly describes when to use it (e.g., no filter lists all communes, sort by -population for largest). It also implies when not to use it (e.g., for individual commune details, use get_commune or commune_at). It provides clear context for filtering and sorting.

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.