New Swiss building permit applications by municipality and trade (last 90 days, official sources).
Scored across 5 tools
Each tool targets a distinct resource or action: application search, nearby municipalities, trade taxonomy, weekly aggregation, and municipality lookup. Overlap is limited to shared context about recent applications, but the boundaries are clear from the names and descriptions.
All names are readable French snake_case and domain-specific, but grammatical patterns vary: chercher_demandes and trouver_commune are verb_noun, while communes_proches, metiers, and resume_semaine are noun phrases. This is a minor deviation from a uniform convention.
Five tools is well within the appropriate 3-15 range for a focused permit-search service. Each tool provides a distinct useful entry point, and none appears redundant.
The read-only surface covers search, geography, trade taxonomy, weekly stats, and municipality lookup, which are the core exploration workflows. A direct get-application-by-id detail endpoint or keyword search could be useful, but most agent needs can be worked around via chercher_demandes.
Search new building permit applications published in Switzerland (Kranli, official publications of the last 90 days) by municipality or canton, trade and period, newest first. Each application comes with its date, municipality, official description, status, trades, link to the official publication, source and mandatory notice ("formule"). / Cherche les nouvelles demandes de permis de construire publiées en Suisse (publications officielles des 90 derniers jours), par commune ou canton, métier et période, les plus récentes d’abord, avec le lien officiel, la source et la formule de chaque demande.
| Name | Required | Description | Default |
|---|---|---|---|
| jours | No | How many days back (at most 90). / Nombre de jours en arrière (90 au plus). | |
| canton | No | Two-letter canton code, e.g. "VS". / Sigle du canton, par exemple « VS ». | |
| langue | No | Language of labels and of the answer (fr, de, it, en). / Langue des libellés et de la réponse. | fr |
| limite | No | Number of applications returned. / Nombre de demandes rendues. | |
| metier | No | Trade: identifier from the metiers tool or a few words, e.g. "heat pump", "pompe à chaleur", "Wärmepumpe", "solaire". / Métier : identifiant ou quelques mots. | |
| commune | No | Municipality: name, postcode or identifier, e.g. "Sion", "1950", "buchs-ag". / Commune : nom, numéro postal ou identifiant. | |
| rayon_km | No | With a municipality: also the municipalities within this many km. / Avec une commune : aussi les communes à moins de N km. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuine value beyond them: the data source ('Kranli, official publications'), the 90-day freshness ceiling, the newest-first ordering, and the exact fields each record carries (date, commune, official description, status, trades, official link, source, mandatory 'formule' notice). It does not mention rate limits or pagination, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, source and ordering before any secondary detail, and every clause carries information. The full bilingual duplication roughly doubles the length, which is a format convention rather than padding, but it does cost some density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by enumerating the returned fields and the sort order, which is exactly what an agent needs to decide whether to call it. Minor gaps remain: nothing about behavior when all filters are omitted, and nothing about how rayon_km widens results in practice or how results are capped.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter, including the 90-day cap on jours and the 25 cap on limite. The description reinforces that commune/canton, metier and period are combinable filters, but it adds no syntax or interaction detail beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource with real scope: 'Search new building permit applications published in Switzerland ... official publications of the last 90 days', filtered by municipality, canton, trade and period, ordered newest first. That is far more informative than the bare tool name. It stops short of 5 because it never names what makes it different from lookup siblings like metiers or trouver_commune, leaving the routing inference to the agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the filter list ('by municipality or canton, trade and period'), so an agent can guess the intended context. But there is no explicit when-to-use, no statement of what to do first when the municipality or trade is unknown (resolve via trouver_commune / metiers), and no exclusion versus alternatives such as resume_semaine.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the municipalities within a radius of a municipality (distance between official centres, rounded to the km), with their recent applications. / Les communes autour d’une commune (distance entre centres officiels, arrondie au kilomètre), avec leurs demandes récentes.
| Name | Required | Description | Default |
|---|---|---|---|
| canton | No | Two-letter canton code, e.g. "VS". / Sigle du canton, par exemple « VS ». | |
| langue | No | Language of labels and of the answer (fr, de, it, en). / Langue des libellés et de la réponse. | fr |
| commune | Yes | Municipality: name, postcode or identifier. / Commune : nom, numéro postal ou identifiant. | |
| rayon_km | No | Radius in km. / Rayon en kilomètres. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The description adds meaningful behavioral context by specifying that distance is between official centres and rounded to the kilometre, and that results include recent applications; it does not define what qualifies as 'recent' or describe result limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The key purpose and scope are front-loaded in one clear sentence. The French translation doubles the length without adding new information for an English-reading agent, but the text remains free of tangential wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-parameter read-only list tool with full schema coverage and no output schema, the description adequately states what is returned: nearby municipalities plus their recent applications. It is slightly incomplete in not defining 'recent applications' or result format, but the essential calling context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented in the schema. The description reinforces the radius concept and distance basis but adds no parameter syntax or constraints beyond what the schema provides, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: list municipalities within a radius of a municipality, including their recent applications. This clearly distinguishes the tool from a single-municipality lookup or a general application search by its radius-based scope, though it does not explicitly name sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the radius-and-recent-applications framing: use it when nearby municipalities and their recent applications are needed. However, there is no explicit when-to-use, when-not-to-use, or alternative guidance (e.g., versus trouver_commune or chercher_demandes).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the ten trade families used by Kranli (heating and heat pumps, solar, windows, roofing, facades, interior, outdoor and pools, new build, civil engineering, electrical) with their identifiers and recent counts. / Les dix familles de métiers de Kranli, avec leurs identifiants et leurs demandes récentes.
| Name | Required | Description | Default |
|---|---|---|---|
| langue | No | Language of labels and of the answer (fr, de, it, en). / Langue des libellés et de la réponse. | fr |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe, idempotent, read-only, closed-world operation, so the safety burden is lifted. The description contributes only the fixed scope (ten families) and the inclusion of recent counts; it says nothing about caching, freshness of the counts, or output shape, leaving the disclosure modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the scope, zero filler words. The bilingual repetition is redundant textually but is plausibly justified for a French/German/Italian/English service, so it costs little.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a trivial fixed-cardinality read tool with annotations covering safety and a fully documented enum parameter, the description supplies enough scope and content detail. Nothing critical is missing, though it could note that the returned counts are recent/rolling demand volumes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter has 100% schema description coverage including an enum and default, so the schema carries the semantics. The description never mentions the langue parameter, adding no meaning beyond what the schema already provides; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (list the ten trade families) and even enumerates all ten families, plus what is returned (identifiers and recent counts). That makes the tool's identity unambiguous, though it never names a sibling to contrast with, so an agent must infer differentiation from content alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance and no mention of alternatives such as chercher_demandes. Usage is only implied by the fact that it returns family identifiers and counts, which an agent would need to filter demandes by trade.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Number of building permit applications of the last 7 days, by canton and by trade. / Le nombre de demandes de permis de construire des 7 derniers jours, par canton et par métier.
| Name | Required | Description | Default |
|---|---|---|---|
| canton | No | Two-letter canton code, e.g. "VS". / Sigle du canton, par exemple « VS ». | |
| langue | No | Language of labels and of the answer (fr, de, it, en). / Langue des libellés et de la réponse. | fr |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, and closed-world behavior. The description adds the aggregation window (last 7 days) and grouping dimensions (canton and trade), but it does not state what happens when canton is omitted or what the returned counts look like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short bilingual sentences deliver the purpose, timeframe, and grouping with no filler. The English/French duplication is purposeful for a bilingual tool and does not obscure the core statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity read-only aggregate with rich annotations and fully described simple parameters, the description covers what is counted, the time window, and the grouping dimensions. The remaining gap is the omitted behavior when no canton is supplied, which the description could state explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents canton's two-letter pattern and langue's enum and default. The description reinforces that results can be grouped by canton, but it does not explain the optional canton parameter's default behavior or langue's effect beyond the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a concrete aggregation: counts of building permit applications over the last 7 days, grouped by canton and trade. That is clear enough to distinguish a weekly summary from a detailed search, but it never names siblings like chercher_demandes or explains why to choose this weekly aggregate over them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance, no mention of sibling tools, and no exclusions or prerequisites. The 'last 7 days' scope implies a weekly-summary use case, but the agent is left to infer usage rather than being told when to select this tool instead of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a Swiss municipality by name or postcode; returns its identifier, canton and number of applications in the last 7, 30 and 90 days. / Trouve une commune suisse par son nom ou son numéro postal : identifiant, canton et nombre de demandes récentes.
| Name | Required | Description | Default |
|---|---|---|---|
| nom | Yes | Name or postcode, e.g. "Sion", "Buchs AG", "8001". / Nom ou numéro postal. | |
| canton | No | Two-letter canton code, e.g. "VS". / Sigle du canton, par exemple « VS ». | |
| langue | No | Language of labels and of the answer (fr, de, it, en). / Langue des libellés et de la réponse. | fr |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds the useful detail that results include counts over 7/30/90 day windows, but says nothing about no-match behavior or whether matching is exact or fuzzy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence per language, with the resource and return payload first. The bilingual duplication is justified for a bilingual tool and no filler sentences are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by naming the returned fields and their time windows, which is the key missing piece for a search tool. Only edge-case behavior (no results, ambiguous multi-canton matches) is left unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents nom, canton and langue with examples and enum values. The description only restates 'by name or postcode' and adds nothing about matching behavior, partial matches, or how canton/langue interact with results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Find a Swiss municipality by name or postcode') and enumerates the returned fields (identifier, canton, application counts), which separates it from siblings like chercher_demandes. It does not explicitly name an alternative tool, keeping it short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the name/postcode lookup is clear, but there is no statement of when to prefer communes_proches or chercher_demandes, nor any prerequisite or exclusion guidance. An agent can infer the context but must reason about sibling choice itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
chercher_demandescommunes_prochesmetiersresume_semainetrouver_communeSwiss building applications: new residential projects, months before they are advertised.
Every official Swiss building application on the day it is published, for professionals.
Official Swiss data for all 26 cantons and 2,100 communes: tax, rent, health premiums, fuel, jobs.
Fresh US building permits with contacts from official city APIs. Construction lead generation.
Add one secure layer between your agents and this server.