Global volcanic eruptions from the Smithsonian Global Volcanism Program: VEI, location, dates.
Free discovery. Returns the list of live agent-ready data packs available on DaedalMap.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already covers the read-only nature, so the description only adds 'live agent-ready' and the fact that it returns a list. It does not disclose additional behaviors like ordering, pagination, or data volume, but given the simple tool and existing annotation, this is acceptable.
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 very short, but the opening fragment 'Free discovery' is vague and adds little value. The main sentence is clear and front-loaded, making it mostly concise with one minor piece of unnecessary phrasing.
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 no-parameter, read-only tool with no output schema, the description states its primary return value. It lacks guidance on how the returned list might be used or how to proceed to related tools, but the tool's simplicity keeps the description reasonably complete.
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?
With zero parameters, the schema coverage is trivially 100% and the description has no need to explain parameter semantics. The baseline for zero-parameter tools is 4, and the description appropriately omits any parameter details.
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 'Returns the list of live agent-ready data packs available on DaedalMap' with a specific verb and resource. It distinguishes itself from sibling tools like get_pack, which retrieves a specific pack, by focusing on the overall catalog.
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 alternative guidance is provided. 'Free discovery' hints at an exploratory purpose, but the description does not mention how this tool relates to get_pack or other siblings, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free linked-disaster helper. Expands one exact disaster event id into a bounded related-event chain. Use this only when you already have an exact event id from a supported pack such as earthquakes, tsunamis, volcanoes, or wildfires.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | Maximum link-chain depth to traverse. Default 1. | |
| pack_id | No | Optional pack id hint when the event id is ambiguous. Supported exact-event link packs are earthquakes, tsunamis, volcanoes, and wildfires. | |
| event_id | Yes | Exact disaster event id from a supported pack row, such as 'NOAA-SIG-2' or 'USA-CA-FIRE-215'. | |
| request_id | No | Optional caller-supplied request id for tracing. | |
| cross_type_only | No | When true, only return cross-hazard links. Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint: true provided in annotations, the description does not need to restate the read-only nature. It adds useful behavioral context by describing the chain as 'bounded' and requiring an exact event id, which implies deterministic expansion. It does not describe return format or pagination, but this is somewhat covered by annotations and the bounded nature. No contradictions found.
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 three sentences, but the first sentence 'Free linked-disaster helper' is vague and adds little value. The remaining sentences are efficient and clearly state the primary purpose and usage condition. Slight waste in the opening phrase prevents a 5.
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 description covers the core behavior and usage condition, and with readOnlyHint and full parameter schema, the tool is well-specified. No output schema exists, but the description hints at the chain outcome. It is complete for a simple read-only helper, though mentioning the depth limit (already in schema) could add clarity.
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 reinforces that event_id must be exact and mentions supported packs, aligning with pack_id. It does not add significant new semantics beyond the schema, but the context of 'bounded chain' implicitly relates to depth. A 3 is appropriate since the schema carries the load.
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 action: 'Expands one exact disaster event id into a bounded related-event chain.' It specifies the resource (exact disaster event id) and scope (bounded chain). It also distinguishes from siblings by noting the requirement for an exact event id and listing supported packs, which differentiates it from search-based tools like search_disaster_links.
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 explicit usage guidance: 'Use this only when you already have an exact event id from a supported pack,' which sets a clear precondition and names the supported packs. However, it does not explicitly name alternative tools or say when not to use it, so it does not fully address the 'vs alternatives' aspect required for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free linked-disaster helper. Resolves one exact disaster event id into its published related-disaster links. Use this only when you already have an exact event id from a supported pack such as earthquakes, tsunamis, volcanoes, or wildfires.
| Name | Required | Description | Default |
|---|---|---|---|
| pack_id | No | Optional pack id hint when the event id is ambiguous. Supported exact-event link packs are earthquakes, tsunamis, volcanoes, and wildfires. | |
| event_id | Yes | Exact disaster event id from a supported pack row, such as 'NOAA-SIG-2' or 'USA-CA-FIRE-215'. | |
| request_id | No | Optional caller-supplied request id for tracing. | |
| cross_type_only | No | When true, only return cross-hazard links. Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the description does not need to restate safety. It adds light behavioral context by noting 'published related-disaster links' and the exact-id requirement, but it does not reveal output format, missing-id behavior, or other behavioral details beyond what annotations and schema indicate.
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 wasted words. It front-loads the purpose and immediately follows with the critical usage constraint, making it easy to scan and act on.
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 no output schema, the description adequately indicates the return concept ('related-disaster links'). It covers the key prerequisite (exact event id) and supported packs. It could mention error behavior or output shape, but for a simple read-only resolver with good annotations and schema, it is sufficiently complete.
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 input schema already thoroughly documents all four parameters. The description adds no significant parameter semantics beyond the schema, though it repeats the supported pack names and exact-id requirement. Baseline 3 is appropriate given the schema does the heavy lifting.
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-resource action: 'Resolves one exact disaster event id into its published related-disaster links.' It clearly distinguishes itself from siblings by emphasizing 'exact event id' versus broader search, and names supported packs including earthquakes, tsunamis, volcanoes, and wildfires.
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?
Explicitly states when to use the tool: 'Use this only when you already have an exact event id from a supported pack.' This provides a clear precondition and implicitly excludes searches without an exact id, though it does not explicitly name an alternative sibling like search_disaster_links.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free live wrapper. Calls the Smithsonian/GVP WFS for recent preliminary volcanic eruption updates normalized to DaedalMap event fields. This is not the enriched canonical history lane.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Recent lookback window in days. Ignored when start_time is provided. | |
| limit | No | Maximum live rows to return. | |
| min_vei | No | Optional minimum Volcanic Explosivity Index. | |
| orderby | No | Result ordering. | |
| end_time | No | Optional inclusive ISO-8601 end datetime or date. Defaults to now. | |
| request_id | No | Optional caller-supplied request id for tracing. | |
| start_time | No | Optional inclusive ISO-8601 start datetime or date. | |
| ongoing_only | No | When true, only return eruptions marked continuing by GVP. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already marks this as a safe read operation, and the description adds context by revealing it is a wrapper around an external WFS service, returning preliminary updates normalized to DaedalMap fields. This informs the agent about the data's provisional nature and external dependency beyond the annotation.
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 redundant wording. It front-loads the core purpose ('Free live wrapper') and quickly moves to the external source and normalization, making it highly efficient and easy to parse.
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 read-only live data tool with a fully documented schema, the description adequately covers the external source, the data's preliminary nature, and its relationship to the canonical lane. However, without an output schema, it does not describe the exact return structure or pagination behavior, but the mention of 'normalized to DaedalMap event fields' gives a useful hint.
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 100% description coverage for all 8 parameters, so the description is not required to explain parameter semantics. The description adds no extra parameter-specific details beyond the schema, and the baseline of 3 is appropriate because the schema carries the full burden.
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 identifies the tool as fetching live volcano events via the Smithsonian/GVP WFS, using a specific verb ('get') and resource ('live volcano events'). It also distinguishes itself from the canonical/enriched history lane, which differentiates it from sibling tools like get_volcanic_activity.
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 that this is a 'free live wrapper' for preliminary updates and explicitly states what it is not: 'not the enriched canonical history lane.' This implies the alternative use case (canonical data) without naming a specific sibling tool, so it stops short of a full when/when-not explanation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free discovery. Returns detailed metadata, coverage, freshness, preferred canonical tool guidance, and first-query examples for one pack. Call this before querying a new pack so you can see time shape, coverage limits, and the paste-ready first query.
| Name | Required | Description | Default |
|---|---|---|---|
| pack_id | Yes | Pack identifier from get_catalog. Newly catalog-admitted packs require no MCP schema change. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds context by calling it 'Free discovery' and explaining it returns coverage limits and time shape, which hints at the nature of the data and potential limitations. It doesn't reveal side effects (none expected) and aligns with the read-only annotation.
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, both purposeful: the first enumerates the return contents, the second gives an actionable usage directive. No wasted words, and the purpose is front-loaded.
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 read-only get tool with no output schema, the description covers what it returns, when to call it, and its purpose. It doesn't mention error handling or invalid pack_id behavior, but those are minor for a tool of this simplicity. Overall, it provides enough information for an agent to call it correctly.
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% with pack_id described as 'Pack identifier from get_catalog.' The description adds no new parameter semantics beyond what the schema provides; it only refers to 'new pack' generally. Given the high coverage, 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?
The description states a specific verb ('Returns') and a specific resource ('detailed metadata... for one pack'), and distinguishes itself from sibling tools like get_catalog by focusing on a single pack rather than a list. The phrase 'one pack' clearly differentiates it from a catalog listing.
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?
Explicitly instructs to 'Call this before querying a new pack' and explains why (to see time shape, coverage limits, and the paste-ready first query). While it doesn't name alternative tools like get_catalog for comparison, the directive is clear and contextually appropriate for this discovery tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free blind-caller guidance for one tool visible on this MCP facade. Returns when to use it, what it refuses, a working example, effective access limits, important outputs, provenance fields, recommended next calls, and the shared natural-language-to-strict-JSON interaction contract. Use tools/list to discover names, then call this before an unfamiliar tool.
| Name | Required | Description | Default |
|---|---|---|---|
| tool_name | Yes | Exact tool name from tools/list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description details the API's behavior by enumerating the types of returned guidance (when to use, refusals, examples, limits, outputs, provenance, next calls, interaction contract). This gives the agent a strong understanding of what to expect without needing to call it.
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 concise with three sentences: purpose, returned content, and usage. The second sentence is a long list but is informative and well-structured. It is front-loaded with the core 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 tool with one parameter and no output schema, the description fully covers what it returns, how to prepare for it, and when to call it. It provides all necessary context for an agent to use it effectively.
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 already fully documents the only parameter (tool_name) with the instruction 'Exact tool name from tools/list.' The description repeats this guidance but adds no new semantic meaning, so the schema does the heavy lifting.
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 provides blind-caller guidance for a single tool on the MCP facade, distinguishing it from sibling data-fetching tools. It also lists specific content returned, making the purpose unmistakable.
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?
Explicitly instructs to use tools/list first and then call this tool before any unfamiliar tool, giving a clear workflow and when-to-use context. This differentiates it from simply invoking the target tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free canonical tool. Queries volcanoes_events for historical eruption records and volcanic activity metrics. Best for eruption counts, VEI thresholds, and top-event lookups. Volcano queries normally use year-style time filters rather than ISO date strings.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Optional sort instructions for row-returning queries. | |
| limit | No | Maximum number of rows to return. For top-N VEI or latest-eruption requests, include a narrow year range or region_ids before sorting. | |
| output | No | Optional output controls such as response format hints. | |
| filters | Yes | Structured filters including year-based time ranges, region_ids, and compare clauses. For most volcano queries, pass numeric years or time.value. | |
| metrics | Yes | Metric ids to return, such as 'event_count', 'VEI', or eruption attributes. | |
| request_id | No | Optional caller-supplied request id for tracing and idempotency. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description only needs to add non-safety context. It adds value by noting this is a 'Free canonical tool,' clarifying it operates on historical records, and providing filter-style expectations (year-based rather than ISO dates). No contradictions with annotations.
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?
Three sentences, each earning its place. First sentence states what it does and cost status, second gives primary use cases, third provides indispensable filter guidance. No repetition of schema details, no filler.
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 6 parameters, nested objects, and no output schema, the description covers the essential decision points: purpose, historical scope, use cases, and filter style. It doesn't describe return shape, but the mention of 'metrics' and 'top-event lookups' implies enough for an agent to select the tool correctly. Slightly more detail on output would push to 5, but current coverage is solid.
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 baseline is 3. The description goes beyond the schema by clarifying that volcano queries 'normally use year-style time filters rather than ISO date strings,' which directly informs how to fill the 'filters' parameter. It also gives concrete metric examples ('event_count', 'VEI'), adding semantic color to a fully documented 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 uses a specific verb ('Queries') and names the resource ('volcanoes_events') with clear scope ('historical eruption records and volcanic activity metrics'). It distinguishes itself from siblings by emphasizing 'historical' vs. live events, and explicitly lists what it's 'best for' (eruption counts, VEI thresholds, top-event lookups).
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 concrete use cases ('Best for eruption counts, VEI thresholds, and top-event lookups') and gives practical guidance on year-style time filters over ISO date strings. It clearly implies historical data context, differentiating it from get_live_volcano_events, though it doesn't explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free linked-disaster discovery helper. Searches published cross-disaster link families by event-type direction, optional via-event type, and optional year window. Use this when you want to discover whether a relationship family exists before you have an exact event id.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of matching chains to return. Default 10. | |
| year_end | No | Optional inclusive ending year filter. | |
| request_id | No | Optional caller-supplied request id for tracing. | |
| year_start | No | Optional inclusive starting year filter. | |
| end_event_type | No | Optional ending event type such as tsunami, flood, tornado, or earthquake. | |
| via_event_type | No | Optional intermediate event type for bounded chain discovery. | |
| start_event_type | No | Optional starting event type such as earthquake, hurricane, volcano, wildfire, flood, tornado, or tsunami. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe-read nature is covered. The description adds context about the search dimensions but does not disclose behavioral traits like return format, pagination, or rate limits. It provides some added context beyond annotations but not rich detail.
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 only two sentences, front-loaded with the core purpose. The phrase 'Free linked-disaster discovery helper' is slightly ambiguous but does not add bloat. Every sentence earns its place, making it appropriately concise.
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 7 optional parameters and no output schema, the description covers the main use case and search criteria well. However, it does not describe the return value structure or clarify how 'limit' and 'request_id' affect behavior. Since there is no output schema, the missing return-format detail leaves a noticeable 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?
With 100% schema description coverage, all seven parameters are fully documented in the schema. The description mentions event-type direction, via-event type, and year window, which maps to the schema fields, but does not add meaning beyond what the schema already 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 clearly states that the tool 'Searches published cross-disaster link families by event-type direction, optional via-event type, and optional year window.' This is a specific verb+resource definition that distinguishes it from siblings like get_disaster_links_for_event, especially since it mentions discovering relationships before having an exact event id.
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 says 'Use this when you want to discover whether a relationship family exists before you have an exact event id.' This provides a clear condition for use and implicitly excludes cases where an event id is already known, though it does not explicitly name an alternative tool.
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. Dates show when Glama detected each change.
get_pack1 field changedInput schema / properties / pack_id / descriptionPrevious value: -"Pack identifier such as 'currency', 'earthquakes', 'floods', 'hurricanes', 'tornadoes', 'tsunamis', 'un_sdg', 'volcanoes', 'world_factbook', or 'worldpop'."New value: +"Pack identifier from get_catalog. Newly catalog-admitted packs require no MCP schema change."get_tool_helpget_disaster_link_chainget_disaster_links_for_eventsearch_disaster_linksget_pack1 field changedInput schema / properties / pack_id / descriptionPrevious value: -"Pack identifier such as 'currency', 'earthquakes', 'volcanoes', 'tsunamis', 'hurricanes', 'un_sdg', 'world_factbook', or 'worldpop'."New value: +"Pack identifier such as 'currency', 'earthquakes', 'floods', 'hurricanes', 'tornadoes', 'tsunamis', 'un_sdg', 'volcanoes', 'world_factbook', or 'worldpop'."get_volcanic_activity2 fields changedInput schema / properties / filters / descriptionPrevious value: -"Structured filters including time ranges, region_ids, and compare clauses."New value: +"Structured filters including year-based time ranges, region_ids, and compare clauses. For most volcano queries, pass numeric years or time.value."Input schema / properties / limit / descriptionPrevious value: -"Maximum number of rows to return. For top-N requests, include a narrow time range or region_ids before sorting."New value: +"Maximum number of rows to return. For top-N VEI or latest-eruption requests, include a narrow year range or region_ids before sorting."get_pack1 field changedInput schema / properties / pack_id / descriptionPrevious value: -"Pack identifier such as 'currency', 'earthquakes', 'volcanoes', 'tsunamis', 'hurricanes', 'un_sdg', or 'world_factbook'."New value: +"Pack identifier such as 'currency', 'earthquakes', 'volcanoes', 'tsunamis', 'hurricanes', 'un_sdg', 'world_factbook', or 'worldpop'."get_earthquake_eventsget_fx_ratesget_live_earthquake_eventsget_tsunami_eventsget_volcanic_activity1 field changedInput schema / properties / limit / descriptionPrevious value: -"Maximum number of rows to return. Use small limits for top-N eruption lookups."New value: +"Maximum number of rows to return. For top-N requests, include a narrow time range or region_ids before sorting."query_datasetget_live_volcano_eventsget_pack1 field changedInput schema / properties / pack_id / descriptionPrevious value: -"Pack identifier such as 'currency', 'earthquakes', 'volcanoes', or 'tsunamis'."New value: +"Pack identifier such as 'currency', 'earthquakes', 'volcanoes', 'tsunamis', 'hurricanes', 'un_sdg', or 'world_factbook'."query_dataset2 fields changedInput schema / properties / pack_id / descriptionPrevious value: -"Pack id such as 'currency', 'earthquakes', 'volcanoes', or 'tsunamis'."New value: +"Pack id such as 'currency', 'earthquakes', 'volcanoes', 'tsunamis', 'hurricanes', 'un_sdg', or 'world_factbook'."Input schema / properties / source_id / descriptionPrevious value: -"Concrete source id such as 'earthquakes_events' or 'volcanoes_events'."New value: +"Concrete source id such as 'earthquakes_events', 'volcanoes_events', 'hurricanes_events', or 'un_sdg/01'."get_live_earthquake_eventsget_catalogget_earthquake_eventsget_fx_ratesget_packget_tsunami_eventsget_volcanic_activityquery_datasetClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Global tsunami events from NOAA NCEI, 2000 BC-present: wave height, runups, and counts.
Global earthquake events from the USGS, 2150 BC-present: magnitude, depth, location, counts.
Global flood events and extent 1985-present from the Dartmouth Flood Observatory and GFD.
Global hurricane and tropical cyclone tracks from IBTrACS/NOAA, 1842-present. Wind and pressure.
Add one secure layer between your agents and this server.
Most tools are clearly distinct, but get_disaster_link_chain and get_disaster_links_for_event both operate on an exact event id and return related events, which could cause confusion. Descriptions clarify chain vs. links, but the boundary is subtle.
All tools follow a consistent get_<resource> or search_<resource> pattern, using snake_case throughout. The naming is predictable and makes it easy to infer function from the tool name.
With 8 tools, the server covers discovery, query, live data, and cross-disaster linking without being bloated. Each tool serves a clear purpose, making the count appropriate for a specialized volcanic activity data server.
The surface covers core volcanic activity queries, live events, pack discovery, and related-disaster exploration. Minor gaps exist such as no direct tool for fetching a single event by ID, but the existing tools can generally work around that.