南西インド洋サイクロン監視のためのMCPサーバー:公式RSMCラ・レユニオンリンク、メテオフランスの警戒情報参照、警報レベルの説明、過去のアーカイブ発見、ラ・レユニオンとマヨットのコミューン距離暴露ヘルパーを提供します。
レユニオン、マヨット、マダガスカル、モーリシャス、モザンビーク海峡、そしてより広い南西インド洋海域向けに設計されています。
cyclone_get_sources — 公式および二次情報源を一覧表示します。
cyclone_get_current_activity — RSMCラ・レユニオンの現在の公開ページを取得し、運用製品リンクを発見します。
cyclone_get_rsmc_archives — 公開されているRSMCアーカイブリンクを取得します。
cyclone_get_vigilance_links — ラ・レユニオンとマヨットの公式メテオフランス警戒リンクを返します。
cyclone_build_monitoring_brief — ソースの優先順位と安全境界を備えたエージェント対応の監視フローを構築します。
cyclone_explain_alert_level — 事前警報、オレンジ、赤、紫、および安全確保のサイクロン段階を説明します。
cyclone_estimate_commune_exposure — サイクロン位置からの距離でレユニオン/マヨットのコミューンをランク付けします。
cyclone_list_communes — 距離ヘルパーが使用する組み込みのコミューン重心を一覧表示します。
cyclone_get_notable_events — 基礎となる注目すべき最近のサイクロンイベントの厳選リスト。
Related MCP server: DevHelm MCP Server
npm install
npm run build
npm test
npm run dev{
"mcpServers": {
"cyclone-indian-ocean": {
"command": "npx",
"args": ["mcp-cyclone-indian-ocean"]
}
}
}主要な情報源:
RSMCラ・レユニオン / メテオフランス熱帯サイクロンセンター: http://www.meteo.fr/temps/domtom/La_Reunion/webcmrs9.0/anglais/index.html
RSMCラ・レユニオンアーカイブ: http://www.meteo.fr/temps/domtom/La_Reunion/webcmrs9.0/anglais/archives/index.html
メテオフランス・ラ・レユニオンサイクロンページ: https://meteofrance.re/fr/cyclone
メテオフランス警戒ラ・レユニオン: https://vigilance.meteofrance.fr/fr/la-reunion
メテオフランス警戒マヨット: https://vigilance.meteofrance.fr/fr/mayotte
GDACS熱帯サイクロン: https://www.gdacs.org/Cyclones/
docs/sources.md を参照してください。
このプロジェクトは緊急警報の権限機関ではありません。エージェントが公式情報を発見し要約するのを支援しますが、ユーザーはサイクロン発生中は県、市民保護、およびメテオフランスの指示に従う必要があります。
METEOFRANCE_API_TOKEN=... npx mcp-cyclone-indian-oceanトークンはオプションです。公開リンクとRSMC発見ツールはトークンなしで動作します。
リポジトリには以下が含まれます:
Dockerfile
glama.json
npm run build
npm test
npm run test:smoke
Glamaでは、次を使用します:
["npm install", "npm run build"]CMD引数:
["node", "dist/index.js"]MIT
Estimate which Réunion or Mayotte communes are geographically closest to a cyclone position. This is a distance helper, not an official impact model.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Cyclone latitude in decimal degrees, negative south of the Equator. | |
| lon | Yes | Cyclone longitude in decimal degrees east. | |
| limit | No | Max communes to return. | |
| radius_km | No | Radius used for within_radius flag. | |
| territory | No | Optional territory filter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral burden. It discloses that it is a helper and explicitly states it is not an official impact model, which is a useful caveat. Yet it does not mention whether it is read-only, what the output format is (no output schema), or any potential limitations like asynchronous behavior or rate limits. The limitation statement adds some transparency but leaves gaps.
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 description is two concise sentences: the first states the core purpose, and the second clarifies its scope and limitation. It is front-loaded, contains zero filler, and every word adds value. This is exemplary conciseness.
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?
Given the tool has 5 well-documented parameters (100% schema coverage) and no output schema, the description provides a sufficient overview: it names the geographic scope, the distance-based nature, and the non-official caveat. It could add a note about the return format, but for a simple helper tool with clear schema, it is adequately complete, especially referencing the territory filter implicitly through 'Réunion or Mayotte.'
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 baseline is 3. The description says 'closest to a cyclone position,' which reinforces that lat/lon are cyclone coordinates, but the schema already describes these parameters thoroughly. The description adds no extra meaning beyond the schema's existing documentation, so it does not exceed the baseline.
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 clearly states the tool's function: 'Estimate which Réunion or Mayotte communes are geographically closest to a cyclone position.' It uses a specific verb ('estimate') and resource ('communes'), and distinguishes itself from sibling tools by explicitly labeling it as a 'distance helper' rather than an official impact model, setting it apart from cyclone_list_communes and alert-related 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?
The description provides implicit usage context by defining its scope as a quick distance-based estimation and cautions that it is 'not an official impact model,' which tells the agent when not to rely on it. However, it does not explicitly name alternative tools or state when to prefer this tool over others, though the sibling list suggests cyclone_list_communes as a contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain French cyclone alert levels used around La Réunion/Mayotte: pre-alert, orange, red, purple, and safeguard phase.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Optional alert level to explain: pre-alert, orange, red, purple, safeguard, or French label. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only lists topics and does not state what the tool returns, whether it explains all levels when no parameter is passed, or whether it provides actionable guidance vs. static definitions. Minimal behavioral context beyond the core purpose is provided.
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 description is a single, front-loaded sentence that states the action, scope, and relevant level names without waste. Every word contributes to the tool's purpose.
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 simple explanatory tool with one optional parameter, the description is largely complete: it names the subject, the geographic context, and the specific alert levels. It would be slightly stronger if it explicitly indicated behavior for the no-parameter case or the response type, but the low complexity makes this a minor gap.
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 schema description already fully documents the single optional parameter and its accepted values, and the tool description simply mirrors those values. Since schema coverage is 100%, the description adds no meaningful semantic value beyond what the schema provides.
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 uses a specific verb ('Explain') tied to a concrete resource ('French cyclone alert levels used around La Réunion/Mayotte') and enumerates the covered levels. It clearly distinguishes itself from sibling tools that fetch sources, activity, archives, or exposure data.
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?
The intended use is implied by the action and subject matter: an agent should call this when the user wants an explanation of alert levels. However, it does not explicitly say when not to use it or point to alternatives like cyclone_get_current_activity for current alert status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the current public RSMC La Réunion cyclone centre page and return discovered operational product links. Useful as the first call when asking whether a South-West Indian Ocean cyclone system is active.
| Name | Required | Description | Default |
|---|---|---|---|
| include_page_excerpt | No | Include a short text excerpt from the RSMC page. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that this is a read-only network fetch of a public page and returns operational product links. It does not detail failure modes or exact response structure, but the core behavior is transparent.
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 description is two concise sentences with a front-loaded verb and no filler. It communicates purpose, output, and usage context efficiently.
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?
Given the low complexity, single optional parameter, and lack of output schema, the description sufficiently explains what happens and when to use the tool. It could add more detail about how to interpret or consume the returned product links, but overall it is appropriate for the tool's simplicity.
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 only parameter, include_page_excerpt, is fully documented in the schema with a clear description and default value. Schema coverage is 100%, so the description does not need to add parameter details, but it also adds no extra semantics beyond the schema.
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 clearly states that the tool fetches the current public RSMC La Réunion cyclone page and returns discovered operational product links. It also defines scope (South-West Indian Ocean cyclone activity) and distinguishes this from archive and source-related siblings.
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?
The description explicitly positions the tool as the first call when determining whether a South-West Indian Ocean cyclone system is active. It provides clear usage context but does not name exclusions or point to specific alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a small curated list of notable recent South-West Indian Ocean cyclone events for prompt grounding and historical exploration.
| Name | Required | Description | Default |
|---|---|---|---|
| territory | No | Optional territory/country relevance filter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the tool 'returns' a list, implying a read-only operation, and mentions 'small curated' which hints at limitations. It doesn't disclose side effects or authentication needs, but for a simple query tool this is adequate.
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 description is a single sentence that front-loads the main purpose and contains no redundant information. It is concise and well-structured.
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?
Given the tool's simplicity (1 optional param, no output schema, no annotations), the description is sufficiently complete. It explains the purpose and scope. It could be more detailed about what constitutes 'notable' but is adequate for a basic tool.
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 schema covers the only parameter (territory) with a complete description ('Optional territory/country relevance filter'), so the tool description adds no additional semantic value. Baseline of 3 is appropriate given 100% schema coverage.
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 uses a specific verb ('return') and identifies a clear resource ('a small curated list of notable recent South-West Indian Ocean cyclone events'). It distinguishes itself from sibling tools like get_current_activity and get_rsmc_archives by focusing on notable recent events for grounding and historical exploration.
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?
The phrase 'for prompt grounding and historical exploration' provides a clear usage context, indicating when to use this tool. However, it does not explicitly mention alternatives or when NOT to use it, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the RSMC La Réunion public archive index and return available archive links. Useful for historical cyclone-season research in the South-West Indian Ocean.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max archive links to return. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states a fetch operation, implying read-only behavior, but does not disclose additional details such as authentication, rate limits, or what the returned links contain. It is adequate for a simple read but lacks depth.
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 description is two sentences with no fluff, front-loading the action and then adding a usage context. Every word earns its place.
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 tool with one optional parameter, no required fields, and no output schema, the description is sufficient. It explains what the tool does and when to use it, and the schema covers the parameter. It could mention the limit parameter, but the schema already does, so it is complete enough.
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 schema alone provides full coverage of the single parameter (limit) with a clear description of its purpose and constraints. The tool description adds no additional semantic meaning beyond what is already in the schema, so the baseline of 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?
The description clearly states the tool fetches the RSMC La Réunion public archive index and returns archive links. It distinguishes from sibling tools by explicitly mentioning historical cyclone-season research, contrasting with current activity and vigilance 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?
The description provides clear context for when to use the tool ('useful for historical cyclone-season research'), which implies it is not for current activity. However, it does not explicitly mention alternatives or when not to use, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List official and secondary sources used by this MCP server for South-West Indian Ocean cyclone monitoring. Includes RSMC La Réunion / Météo-France, vigilance pages, WMO advisory directory, GDACS, and optional Météo-France API portal.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It describes a read-only listing operation ('List...'), but does not explicitly state that it has no side effects, requires no permissions, or has any rate limits. Since it's a simple list, the risk is low, but transparency is lacking without explicit statements about behavior.
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 description is a single sentence that directly states the purpose and lists examples. It is concise, front-loaded, and contains no fluff or redundancy.
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?
The tool has no output schema, so the description must convey what is returned. It clearly states that it lists sources, implying a list of source identifiers or names. It does not specify the exact format (e.g., array of strings), but for a simple listing operation, this is sufficient and complete within context.
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 input schema has no parameters (empty properties), so schema coverage is 100%. The description adds no parameter-specific information, but given there are zero parameters, the baseline of 3 is appropriate; the description does not need to explain parameters.
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 clearly states the tool lists official and secondary sources used by this MCP server for South-West Indian Ocean cyclone monitoring. It mentions specific sources (RSMC La Réunion, Météo-France, vigilance pages, GDACS, API portal), which distinguishes it from sibling tools that handle other cyclone data operations.
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?
The description indicates the tool's scope (sources used by this server) and purpose (listing sources), which implicitly tells when to use it (when needing to know available sources). It does not explicitly contrast with alternatives, but the specificity of 'sources' and the mention of the server's usage provide adequate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return official vigilance links for La Réunion and Mayotte, plus token configuration status for future Météo-France API-backed calls.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the return includes official links and token configuration status, but does not explain what 'token configuration status' means (e.g., whether this triggers network calls, requires auth), nor does it disclose side effects or data source behavior. Under-specified for a tool that likely connects to external services.
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?
Single sentence, directly states the core function and the additional status info. No fluff; every word contributes. Front-loaded with the primary purpose.
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?
Given it's a no-parameter tool with no output schema and no annotations, the description must cover return format and behavioral caveats. It mentions token configuration status but omits details like link format, whether they are live or static, or what the status indicates. For a tool in a cyclone context, users may need to know if this is safe to call repeatedly or has rate limits.
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 schema has zero parameters, so the description does not need to explain parameters. Baseline is 4 for no-parameter tools, and the description correctly focuses on what it returns, adding value beyond the empty schema.
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 the tool returns official vigilance links for two specific territories (La Réunion and Mayotte) and additionally reports token configuration status. This is specific about the resource (vigilance links) and distinguishes it from siblings like cyclone_get_sources or cyclone_get_current_activity, though it does not explicitly contrast with 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?
It implies use for fetching vigilance links and checking token configuration, but does not explicitly state when to use this vs alternatives. No exclusions or mention of related tools for deeper context, so it's adequate but lacks explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List built-in commune centroids used by cyclone_estimate_commune_exposure for La Réunion and Mayotte.
| Name | Required | Description | Default |
|---|---|---|---|
| territory | No | Optional territory filter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of disclosing behavior. It is a read-only operation (list), but it doesn't explicitly confirm that it has no side effects. It also doesn't describe output format or any potential data limitations. It doesn't contradict annotations (none exist), but it adds only minimal context. A 3 is appropriate.
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 description is a single sentence, front-loaded with the verb 'List' and the resource. It conveys the tool's purpose and its relationship to another tool without any wasted words. It is concise and clearly structured.
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?
The tool is simple: one optional parameter, clear purpose, no output schema. The description adequately communicates what the tool does and its relationship to a sibling. Given its low complexity, it is nearly complete, but it could have mentioned the layout of the output (e.g., 'returns the list of commune names and centroids') for completeness. However, it does not need much more, making a 4 appropriate.
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 schema itself has full coverage (100%) with a `territory` parameter and an enum of possible values. The description adds the context that the list is for La Réunion and Mayotte, which reinforces the parameter's purpose. Since schema coverage is high, a baseline of 3 is expected, but the description's explicit mention of territory values adds a slight bonus, making it a 4.
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 clearly states 'List built-in commune centroids used by cyclone_estimate_commune_exposure for La Réunion and Mayotte.' It specifies the verb 'List' and the resource 'commune centroids', and it distinguishes itself from siblings by naming its purpose as a support tool for another tool. It could be slightly more explicit about the return format, but it is clear.
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?
The description implies usage context: it is a listing tool for centroids used by another tool, so it is likely called by users who want to see available data before running exposure estimates. However, it does not explicitly state when to use this vs. alternatives, nor does it mention any exclusions or prerequisites. It is adequate but lacks explicit guidance.
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.
v0.1.0cyclone_estimate_commune_exposurecyclone_explain_alert_levelcyclone_get_current_activitycyclone_get_notable_eventscyclone_get_rsmc_archivescyclone_get_sourcescyclone_get_vigilance_linkscyclone_list_communesScored across 8 tools
Each tool targets a distinct aspect of cyclone monitoring: sources, current activity, archives, vigilance links, alert levels, commune exposure, commune listings, and notable events. No two tools overlap in purpose, making selection straightforward.
All tool names follow the consistent pattern 'cyclone_' plus a verb_noun descriptor (e.g., get_sources, explain_alert_level, list_communes). The naming is uniform and predictable.
With 8 tools, the set is well-scoped for a specialized cyclone monitoring server. Each tool serves a clear function without redundancy or unnecessary bloat.
The surface covers core activities: checking current conditions, historical archives, source listing, vigilance alerts, alert level explanations, and geographic exposure estimation. Minor gaps exist (e.g., no direct forecast fetch), but the provided tools cover the primary workflows without dead ends.
An MCP server that through www.gdacs.org provides access to web‐based disaster information systems.
ReliefWeb MCP — the UN OCHA humanitarian information service.
GDACS MCP — Global Disaster Alert and Coordination System.
Réunion Open Data (data.regionreunion.com) — OpenDataSoft MCP.
