Skip to main content
Glama
Sign In
ph-civic-data-mcp

ph-civic-data-mcp

by xmpuspus
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Philippine volcano alert levels

get_volcano_status
Read-onlyIdempotent

Retrieves current alert levels for monitored Philippine volcanoes from PHIVOLCS. Accepts an optional volcano name to filter results for a single volcano.

Instructions

Get current alert level for Philippine volcanoes.

Reads the WOVODAT bulletin list PHIVOLCS publishes for its monitored volcanoes: Mayon, Taal, Kanlaon, Bulusan, Pinatubo, Hibok-Hibok, and Parker. When one volcano's bulletin fetch fails, that entry carries upstream_error true and a caveat with the real error, not a null alert_level. Examples:

get_volcano_status() all monitored volcanoes, one call get_volcano_status("Mayon") one volcano by name get_volcano_status("Taal")

On failure: WOVODAT list unreachable or empty gives data_status "unavailable", upstream_error true, results: [], and the real error in caveats. An unmatched volcano_name gives a one-item list with alert_level null and a caveat, not a failure envelope.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_volcano_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
volcano_nameNoe.g. "Mayon", "Taal", "Kanlaon", "Bulusan". None returns all monitored volcanoes with recent bulletins.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.5.0
    • addedOutput schema / properties / result / anyOf
      Added value: +[
+  {
+    "items": {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    "type": "array"
+  },
+  {
+    "additionalProperties": true,
+    "type": "object"
+  }
+]
    • removedOutput schema / properties / result / items
      Removed value: -{
-  "additionalProperties": true,
-  "type": "object"
-}
    • removedOutput schema / properties / result / type
      Removed value: -"array"
  2. Addedv0.4.0
  3. Removedv1.0.4
  4. Addedv1.0.2

TDQS

A4.7/5.0
Behavior5/5

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

The description fully discloses failure modes: per-entry fetch failures produce upstream_error and caveat instead of null alert_level, and unreachable/empty lists yield data_status 'unavailable', upstream_error true, empty results, and error in caveats. This matches the readOnly and idempotent annotations.

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

Conciseness4/5

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

The description is logically organized with examples and failure cases, but it is slightly verbose and repeats some details (e.g., failure behavior is mentioned twice). Still, it remains focused and readable.

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 the output schema exists, the description doesn't need to enumerate return fields, but it does mention key fields (data_status, upstream_error, results, caveats) in failure scenarios, providing enough context for callers to handle errors without additional lookup.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description for volcano_name is comprehensive, including examples and the special case of None returning all monitored volcanoes. There are no enums, but the free-form string is adequately explained.

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 'Get current alert level for Philippine volcanoes' and specifies the data source (WOVODAT bulletin list). It is distinct from sibling tools covering earthquakes, weather, and other data.

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

Usage Guidelines4/5

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

Provides explicit examples for calling with no arguments or with a volcano name, and describes behavior when the list is unreachable or a name is unmatched. However, it does not explicitly contrast with sibling tools or state when to prefer this tool over others.

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

Deploy Server

Other Tools