Global flood events and extent 1985-present from the Dartmouth Flood Observatory and GFD.
Scored across 5 tools
Each tool has a clearly distinct purpose: catalog discovery, pack inspection, row retrieval, event drill-down, and help. Even though get_catalog and get_pack both support progressive exploration, one is for discovering options and the other for inspecting a selected item.
All tools follow a consistent get_<noun> pattern using snake_case. The naming clearly signals the action and target, making the toolset predictable and easy to navigate.
Five tools is well-scoped for a focused flood-event data server. Each tool earns its place, covering discovery, metadata inspection, data retrieval, event retrieval, and onboarding/help.
The core read-only workflow is covered: discover catalog, inspect pack, query rows, and drill into a specific event. The only minor gap is that geometry-family specific next-step tools are referenced but not exposed in this tool set.
Discover data packs or geometry families progressively: lite selection, full metric/query inventory, or a raw catalog download URL. Choose one result and call get_pack next. Current catalog: The same geography tools work worldwide across a cataloged baseline of 252 geographic entities, reaching up to Admin 2. Where additional country releases are available, the same calls automatically return deeper administrative tiers or maintained reference families. Additional detail is currently available for Australia, Brazil, Canada, France, Germany, Mexico, United Kingdom, United States.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Use lite to select a pack, full for expanded metric/query inventories, or download for the complete raw catalog URL. | lite |
| loc_id | No | Optional DaedalMap loc_id for catalog='data'. Combine with time_range to discover packs confirmed for both place and time. For place details without pack filtering, use get_loc_id_info. | |
| catalog | No | Catalog family. The geography facade defaults to geometry; other facades default to data. | data |
| time_range | No | Optional inclusive discovery window for catalog='data'. At least one bound is required. | |
| country_scope | No | Optional ISO3 focus for catalog='geometry' with detail='lite'. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| packs | No | |
| detail | No | |
| reason | No | |
| catalog | No | |
| guidance | No | |
| warnings | No | |
| next_step | No | |
| pack_count | No | |
| provenance | No | |
| request_id | No | |
| download_url | No | |
| generated_at | No | |
| clarification | No | |
| tool_families | No | |
| catalog_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description doesn't repeat those. It adds valuable behavioral context: the tool automatically returns deeper administrative tiers for certain countries, and the progressive discovery behavior. This goes beyond annotations and helps the agent understand the tool's adaptive output.
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 first sentence is efficient and front-loaded, stating the core function and the three discovery levels. The second sentence gives workflow guidance. The second paragraph adds catalog scope context, which is useful but slightly verbose. Overall, it's well-structured and each sentence 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?
Given the tool's complexity (5 optional parameters, nested object, enums) and the presence of an output schema, the description is complete. It explains the catalog's geographic scope and the progressive workflow, which the schema does not. It doesn't need to cover return values because the output schema exists. The description provides sufficient context for correct invocation.
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 each parameter already has clear documentation. The main description doesn't add parameter-specific semantics beyond the workflow context (e.g., progressive detail levels), which the schema already explains. This meets the baseline of 3 for high 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 clearly states the tool's purpose: to discover data packs or geometry families with progressive levels (lite, full, download). It distinguishes itself from get_pack by explicitly routing the agent to call get_pack next, and from get_data by focusing on catalog listing rather than data retrieval. The verb 'discover' and resource 'catalog' are specific.
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 a clear workflow: start with lite to select a pack, then call get_pack. It also mentions that get_loc_id_info is the alternative for place details without pack filtering (in the parameter description). However, it doesn't explicitly state when not to use this tool versus get_data or get_tool_help, though the workflow implication is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve rows from one selected published data pack using exact metrics, loc_id-based region filters, time/metric filters, sorting, and a row limit. Disaster event rows include stable event_id values for get_event drill-down. A parent administrative loc_id selects matching descendant rows at the pack's published grain. Call get_pack first; geometry families use their focused next-step tools.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by a sortable field from get_pack; direction defaults to asc. | |
| limit | No | Maximum number of rows to return for the requested source or pack. | |
| output | No | Optional response controls. v1 supports rows only. | |
| filters | Yes | ||
| metrics | Yes | Exact metric ids from get_pack. Use event_count for aggregate counts only when get_pack publishes it. | |
| pack_id | Yes | Pack identifier from get_catalog. Newly catalog-admitted packs require no MCP schema change. | |
| request_id | No | Optional caller-supplied request id for tracing and idempotency. |
| Name | Required | Description |
|---|---|---|
| rows | No | |
| sort | No | |
| error | No | |
| limit | No | |
| reason | No | |
| pack_id | No | |
| guidance | No | |
| warnings | No | |
| next_step | No | |
| row_count | No | |
| source_id | No | |
| truncated | No | |
| provenance | No | |
| query_mode | No | |
| request_id | No | |
| capability_id | No | |
| clarification | No | |
| filters_applied | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only, idempotent, non-destructive behavior. The description adds value by disclosing stable event_id values for get_event drill-down and that a parent administrative loc_id selects descendant rows at the pack's published grain. These behavioral details go beyond the annotation flags and do not contradict them.
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 four sentences, front-loaded with the core purpose and followed by behavioral routing details. Every sentence contributes information; there is no filler or restatement of the tool name.
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 seven parameters and nested objects, the description plus rich schema and annotations cover prerequisites, sibling routing, regional hierarchy behavior, and the event drill-down path. The output schema exists, so the description does not need to document return values.
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 86%, so parameter semantics are mostly carried by the input schema. The description's phrases such as 'exact metrics' and 'loc_id-based region filters' reinforce, but do not materially extend, the schema descriptions for metrics, filters, and region_ids.
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 opens with a specific action and resource: 'Retrieve rows from one selected published data pack' and enumerates the filtering, sorting, and limiting semantics. It also distances itself from siblings by saying 'Call get_pack first' and pointing geometry families to focused tools, so an agent can tell get_data apart from get_catalog, get_pack, and get_event without opening the schema.
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 gives a clear prerequisite ('Call get_pack first') and an explicit exclusion ('geometry families use their focused next-step tools'). It also describes the get_event drill-down path. It does not enumerate every sibling-selection condition, such as when to use get_catalog versus get_pack, so it stops short of full coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve one exact disaster event and explicitly requested relationships, affected places, native observations, or geometry. Use get_data to obtain the stable event_id first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Per-section ceiling for relationships, affected places, observations, or geometry frames. | |
| include | No | Optional companion layers. Omit for the lightweight event summary. Geometry is never returned implicitly. | |
| pack_id | No | Optional disaster pack hint. Recommended when known to avoid probing unrelated event sources. | |
| event_id | Yes | Exact stable event_id returned by a disaster-pack get_data row. | |
| request_id | No | Optional caller-supplied request id for tracing. | |
| geometry_mode | No | current returns the representative/current shape; timeline returns bounded progression frames where supported. | current |
| relationship_depth | No | Bounded cross-hazard traversal depth when relationships is included. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| event | No | |
| reason | No | |
| pack_id | No | |
| event_id | No | |
| geometry | No | |
| guidance | No | |
| included | No | |
| warnings | No | |
| available | No | |
| next_step | No | |
| source_id | No | |
| event_type | No | |
| next_steps | No | |
| provenance | No | |
| request_id | No | |
| observations | No | |
| schema_class | No | |
| clarification | No | |
| relationships | No | |
| affected_places | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, so the description's additional burden is lower. The description adds value by emphasizing exact matching, explicitly requested companion layers, and the prerequisite relationship to get_data, which helps set operational expectations beyond the structured hints.
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 focused sentences with no filler. The first sentence front-loads the core purpose, and the second provides the essential operational prerequisite. Every word contributes to selection or invocation.
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 a complete input schema, output schema, and safety annotations, the description supplies the one critical missing operational detail: where to obtain a valid event_id. The tool is complex enough that a bit more about default lightweight behavior could help, but the schema already covers include and defaults, so no significant gap remains.
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 documents all parameters, defaults, enums, and constraints. The description does not need to restate these details; it adds modest alignment by mentioning the layer categories, but no substantial parameter 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 states a specific verb ('Retrieve'), a precise resource ('one exact disaster event'), and the optional companion layers. It clearly differentiates from get_data, get_catalog, and get_pack by focusing on single-event retrieval rather than listing or fetching event_id sources.
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 instructs the agent to use get_data first to obtain the stable event_id, which is the key prerequisite for correct invocation. It does not exhaustively state when not to use get_event versus every sibling, but the prerequisite guidance and exact-event framing make the intended use context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect one selected data pack or geometry family progressively: lite starter contract, full MCP query metadata, or a raw metadata download URL. Use its next_step to retrieve data or call the preferred geometry tool.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Use lite to decide and start, full for detailed MCP query metadata, or download for the complete raw metadata file. | lite |
| catalog | No | Metadata family. When omitted, geometry facades default to geometry and known geometry-family ids are inferred; all other calls default to data. | |
| pack_id | Yes | Pack identifier from get_catalog. Newly catalog-admitted packs require no MCP schema change. | |
| release_unit | No | Optional non-country geometry release unit such as GLOBAL or MARINE. Do not combine with country_scope. | |
| country_scope | No | Optional ISO3 country for a geometry family. Omit it to learn which countries publish the family; provide it for country-specific versions, vintages, levels, and artifacts. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| detail | No | |
| reason | No | |
| catalog | No | |
| pack_id | No | |
| sources | No | |
| guidance | No | |
| warnings | No | |
| full_call | No | |
| next_step | No | |
| provenance | No | |
| request_id | No | |
| download_url | No | |
| clarification | No | |
| download_call | No | |
| material_policy | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds behavioral value by revealing that results include a next_step for progression and that detail levels map to lite vs full metadata vs download URL. This goes beyond what annotations alone provide.
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 tight sentences front-load the core purpose and then give the key follow-up behavior. There is no filler or redundant restatement of the schema.
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 a rich input schema and an output schema, the description covers the essential workflow and progression. The only mild gap is that 'preferred geometry tool' is not named explicitly, but the sibling list and schema make the intended routing reasonably discoverable.
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 all parameters in detail. The description adds only mild semantic framing ('lite starter contract') and mostly restates the detail-level behavior already present in the schemas.
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, 'Inspect', and a specific resource, 'one selected data pack or geometry family', and names three progressive modes (lite, full, download). It also differentiates from siblings by framing get_pack as operating on a single selected item while get_catalog lists and get_data retrieves 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 description gives actionable guidance: use it to inspect a selected pack, and then 'Use its next_step to retrieve data or call the preferred geometry tool.' It implies a sequential workflow but does not explicitly state when to prefer get_data or get_catalog instead, so it falls just short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe one tool visible on this facade, including its exact contract, or return a bounded workflow overview for one supported topic.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Workflow overview. Do not combine with tool_name. | |
| question | No | Optional question used only with a topic overview. | |
| tool_name | No | Exact tool name from tools/list. Do not combine with topic. |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| title | No | |
| access | No | |
| reason | No | |
| purpose | No | |
| examples | No | |
| guidance | No | |
| warnings | No | |
| next_step | No | |
| tool_name | No | |
| provenance | No | |
| request_id | No | |
| input_schema | No | |
| clarification | No | |
| recommended_next_calls | No | |
| important_output_fields | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds a bit of behavioral context by mentioning 'exact contract' and 'bounded workflow overview', but it does not disclose potential error conditions or response formats. This is acceptable given the annotations, so 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, well-structured sentence that efficiently presents both modes without redundancy. Every phrase adds value, and it is front-loaded with the primary action.
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 is adequate but relies heavily on the schema for constraints (e.g., oneOf logic, enum values, mutual exclusivity). It does not mention optional parameters or edge cases, but given the rich schema and annotations, it covers the essential purpose. A 3 reflects that it is sufficient but not exhaustive.
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% and each parameter already has a thorough description (e.g., 'Do not combine with tool_name'). The tool description adds no extra parameter detail beyond 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's purpose: describe a tool (with its exact contract) or return a workflow overview for a supported topic. It uses specific verbs and resources, and the two modes are distinct. This differentiates it from sibling data-fetching tools like get_data and get_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?
The description implies when to use each mode by stating the two options, and the schema enforces mutual exclusivity. However, it does not explicitly name alternatives or state when NOT to use this tool (e.g., for actual data retrieval). Still, the purpose is clear enough for an agent to infer correct usage.
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.
get_data13 fields changedInput schema / properties / filters / additionalPropertiesAdded value: +{
+ "anyOf": [
+ {
+ "type": [
+ "string",
+ "number",
+ "integer",
+ "boolean",
+ "null"
+ ]
+ },
+ {
+ "items": {
+ "type": [
+ "string",
+ "number",
+ "integer",
+ "boolean"
+ ]
+ },
+ "type": "array"
+ }
+ ]
+}Input schema / properties / filters / descriptionRemoved value: -"Structured filters including time, region_ids, and compare clauses."Input schema / properties / filters / propertiesAdded value: +{
+ "compare": {
+ "description": "Threshold filters using filterable fields or selected metric ids published by get_pack.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "field": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "=",
+ "!=",
+ ">",
+ ">=",
+ "<",
+ "<="
+ ],
+ "type": "string"
+ },
+ "value": {}
+ },
+ "required": [
+ "field",
+ "op",
+ "value"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "equals": {
+ "additionalProperties": {
+ "anyOf": [
+ {
+ "type": [
+ "string",
+ "number",
+ "integer",
+ "boolean",
+ "null"
+ ]
+ },
+ {
+ "items": {
+ "type": [
+ "string",
+ "number",
+ "integer",
+ "boolean"
+ ]
+ },
+ "type": "array"
+ }
+ ]
+ },
+ "description": "Exact field/value filters using filterable fields published by get_pack.",
+ "type": "object"
+ },
+ "region_ids": {
+ "description": "Canonical country or hierarchical loc_ids from get_pack, such as JPN or USA-TX.",
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array",
+ "uniqueItems": true
+ },
+ "time": {
+ "additionalProperties": false,
+ "anyOf": [
+ {
+ "required": [
+ "value"
+ ]
+ },
+ {
+ "required": [
+ "start"
+ ]
+ },
+ {
+ "required": [
+ "end"
+ ]
+ }
+ ],
+ "description": "Inclusive ISO-8601 date/datetime or integer-year selection. Use YYYY-MM-DD, not partial YYYY-MM strings.",
+ "properties": {
+ "end": {
+ "anyOf": [
+ {
+ "format": "date-time",
+ "type": "string"
+ },
+ {
+ "format": "date",
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ }
+ ]
+ },
+ "granularity": {
+ "enum": [
+ "daily",
+ "weekly",
+ "monthly",
+ "yearly",
+ "timestamp"
+ ],
+ "type": "string"
+ },
+ "start": {
+ "anyOf": [
+ {
+ "format": "date-time",
+ "type": "string"
+ },
+ {
+ "format": "date",
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ }
+ ]
+ },
+ "value": {
+ "anyOf": [
+ {
+ "format": "date-time",
+ "type": "string"
+ },
+ {
+ "format": "date",
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ }
+}Input schema / properties / metrics / descriptionPrevious value: -"Metric ids to return. Use event_count for aggregate counts when supported."New value: +"Exact metric ids from get_pack. Use event_count for aggregate counts only when get_pack publishes it."Input schema / properties / metrics / items / minLengthAdded value: +1Input schema / properties / metrics / minItemsAdded value: +1Input schema / properties / metrics / uniqueItemsAdded value: +trueInput schema / properties / output / additionalPropertiesAdded value: +falseInput schema / properties / output / descriptionPrevious value: -"Optional output controls such as response format hints."New value: +"Optional response controls. v1 supports rows only."Input schema / properties / output / propertiesAdded value: +{
+ "format": {
+ "default": "rows",
+ "enum": [
+ "rows"
+ ],
+ "type": "string"
+ },
+ "include_provenance": {
+ "default": false,
+ "type": "boolean"
+ }
+}Input schema / properties / pack_id / minLengthAdded value: +1Input schema / properties / sort / anyOfPrevious value: -[
- {
- "type": "array"
- },
- {
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "direction": {
+ "enum": [
+ "asc",
+ "desc"
+ ],
+ "type": "string"
+ },
+ "field": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "field"
+ ],
+ "type": "object"
+ },
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "direction": {
+ "enum": [
+ "asc",
+ "desc"
+ ],
+ "type": "string"
+ },
+ "field": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "field"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+]Input schema / properties / sort / descriptionPrevious value: -"Optional sort instructions for row-returning queries."New value: +"Sort by a sortable field from get_pack; direction defaults to asc."get_catalog2 fields changedInput schema / properties / loc_idAdded value: +{
+ "description": "Optional DaedalMap loc_id for catalog='data'. Combine with time_range to discover packs confirmed for both place and time. For place details without pack filtering, use get_loc_id_info.",
+ "type": "string"
+}Input schema / properties / time_rangeAdded value: +{
+ "additionalProperties": false,
+ "description": "Optional inclusive discovery window for catalog='data'. At least one bound is required.",
+ "properties": {
+ "end": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ }
+ ]
+ },
+ "start": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ }
+ ]
+ }
+ },
+ "type": "object"
+}get_catalog9 fields changedInput schema / properties / catalogAdded value: +{
+ "default": "data",
+ "description": "Catalog family. The geography facade defaults to geometry; other facades default to data.",
+ "enum": [
+ "data",
+ "geometry"
+ ],
+ "type": "string"
+}Input schema / properties / country_scopeAdded value: +{
+ "description": "Optional ISO3 focus for catalog='geometry' with detail='lite'.",
+ "type": "string"
+}Input schema / properties / detailAdded value: +{
+ "default": "lite",
+ "description": "Use lite to select a pack, full for expanded metric/query inventories, or download for the complete raw catalog URL.",
+ "enum": [
+ "lite",
+ "full",
+ "download"
+ ],
+ "type": "string"
+}Output schema / anyOfPrevious value: -[
- {
- "required": [
- "packs"
- ]
- },
- {
- "required": [
- "error"
- ]
- }
-]New value: +[
+ {
+ "required": [
+ "catalog",
+ "detail"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / catalogAdded value: +{
+ "enum": [
+ "data",
+ "geometry"
+ ],
+ "type": "string"
+}Output schema / properties / detailAdded value: +{
+ "enum": [
+ "lite",
+ "full",
+ "download"
+ ],
+ "type": "string"
+}Output schema / properties / download_urlAdded value: +{
+ "type": "string"
+}Output schema / properties / next_step / anyOfAdded value: +[
+ {
+ "required": [
+ "action"
+ ]
+ },
+ {
+ "required": [
+ "tool"
+ ]
+ }
+]Output schema / properties / next_step / requiredRemoved value: -[
- "action"
-]get_dataget_eventget_pack13 fields changedInput schema / properties / catalogAdded value: +{
+ "description": "Metadata family. When omitted, geometry facades default to geometry and known geometry-family ids are inferred; all other calls default to data.",
+ "enum": [
+ "data",
+ "geometry"
+ ],
+ "type": "string"
+}Input schema / properties / country_scopeAdded value: +{
+ "description": "Optional ISO3 country for a geometry family. Omit it to learn which countries publish the family; provide it for country-specific versions, vintages, levels, and artifacts.",
+ "pattern": "^[A-Za-z]{3}$",
+ "type": "string"
+}Input schema / properties / detail / descriptionPrevious value: -"Use lite for normal discovery. Use full only for one selected pack when its complete public metadata is required."New value: +"Use lite to decide and start, full for detailed MCP query metadata, or download for the complete raw metadata file."Input schema / properties / detail / enumPrevious value: -[
- "lite",
- "full"
-]New value: +[
+ "lite",
+ "full",
+ "download"
+]Input schema / properties / release_unitAdded value: +{
+ "description": "Optional non-country geometry release unit such as GLOBAL or MARINE. Do not combine with country_scope.",
+ "pattern": "^[A-Za-z0-9_-]+$",
+ "type": "string"
+}Output schema / anyOfPrevious value: -[
- {
- "required": [
- "pack_id"
- ]
- },
- {
- "required": [
- "error"
- ]
- }
-]New value: +[
+ {
+ "required": [
+ "catalog",
+ "pack_id",
+ "detail"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / catalogAdded value: +{
+ "enum": [
+ "data",
+ "geometry"
+ ],
+ "type": "string"
+}Output schema / properties / detailAdded value: +{
+ "enum": [
+ "lite",
+ "full",
+ "download"
+ ],
+ "type": "string"
+}Output schema / properties / download_callAdded value: +{
+ "type": "object"
+}Output schema / properties / download_urlAdded value: +{
+ "type": "string"
+}Output schema / properties / full_callAdded value: +{
+ "type": "object"
+}Output schema / properties / next_step / anyOfAdded value: +[
+ {
+ "required": [
+ "action"
+ ]
+ },
+ {
+ "required": [
+ "tool"
+ ]
+ }
+]Output schema / properties / next_step / requiredRemoved value: -[
- "action"
-]get_tool_help7 fields changedInput schema / oneOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "topic"
+ ]
+ },
+ "required": [
+ "tool_name"
+ ]
+ },
+ {
+ "not": {
+ "required": [
+ "tool_name"
+ ]
+ },
+ "required": [
+ "topic"
+ ]
+ }
+]Input schema / properties / questionAdded value: +{
+ "description": "Optional question used only with a topic overview.",
+ "type": "string"
+}Input schema / properties / tool_name / descriptionPrevious value: -"Exact tool name from tools/list."New value: +"Exact tool name from tools/list. Do not combine with topic."Input schema / properties / topicAdded value: +{
+ "description": "Workflow overview. Do not combine with tool_name.",
+ "enum": [
+ "overview",
+ "data",
+ "disasters",
+ "custom_data",
+ "geometry"
+ ],
+ "type": "string"
+}Input schema / requiredRemoved value: -[
- "tool_name"
-]Output schema / properties / next_step / anyOfAdded value: +[
+ {
+ "required": [
+ "action"
+ ]
+ },
+ {
+ "required": [
+ "tool"
+ ]
+ }
+]Output schema / properties / next_step / requiredRemoved value: -[
- "action"
-]query_datasetsearch_disaster_linksget_pack1 field changedInput schema / properties / detailAdded value: +{
+ "default": "lite",
+ "description": "Use lite for normal discovery. Use full only for one selected pack when its complete public metadata is required.",
+ "enum": [
+ "lite",
+ "full"
+ ],
+ "type": "string"
+}get_catalog1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": true,
+ "anyOf": [
+ {
+ "required": [
+ "packs"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+ ],
+ "properties": {
+ "catalog_version": {
+ "type": "string"
+ },
+ "clarification": {
+ "type": "object"
+ },
+ "error": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "details": {
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "retry_hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "generated_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "guidance": {
+ "type": "object"
+ },
+ "next_step": {
+ "additionalProperties": true,
+ "properties": {
+ "action": {
+ "type": "string"
+ },
+ "arguments": {
+ "type": "object"
+ },
+ "tool": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "action"
+ ],
+ "type": "object"
+ },
+ "pack_count": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "packs": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "provenance": {
+ "type": "object"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "request_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "tool_families": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "warnings": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}get_pack1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": true,
+ "anyOf": [
+ {
+ "required": [
+ "pack_id"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+ ],
+ "properties": {
+ "clarification": {
+ "type": "object"
+ },
+ "error": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "details": {
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "retry_hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "guidance": {
+ "type": "object"
+ },
+ "material_policy": {
+ "type": "object"
+ },
+ "next_step": {
+ "additionalProperties": true,
+ "properties": {
+ "action": {
+ "type": "string"
+ },
+ "arguments": {
+ "type": "object"
+ },
+ "tool": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "action"
+ ],
+ "type": "object"
+ },
+ "pack_id": {
+ "type": "string"
+ },
+ "provenance": {
+ "type": "object"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "request_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "sources": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "warnings": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}get_tool_help1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": true,
+ "anyOf": [
+ {
+ "required": [
+ "ok",
+ "tool_name"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+ ],
+ "properties": {
+ "access": {
+ "type": "object"
+ },
+ "clarification": {
+ "type": "object"
+ },
+ "error": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "details": {
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "retry_hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "examples": {
+ "type": "array"
+ },
+ "guidance": {
+ "type": "object"
+ },
+ "important_output_fields": {
+ "type": "array"
+ },
+ "input_schema": {
+ "type": "object"
+ },
+ "next_step": {
+ "additionalProperties": true,
+ "properties": {
+ "action": {
+ "type": "string"
+ },
+ "arguments": {
+ "type": "object"
+ },
+ "tool": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "action"
+ ],
+ "type": "object"
+ },
+ "ok": {
+ "type": "boolean"
+ },
+ "provenance": {
+ "type": "object"
+ },
+ "purpose": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "recommended_next_calls": {
+ "type": "array"
+ },
+ "request_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "tool_name": {
+ "type": "string"
+ },
+ "warnings": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}query_dataset1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": true,
+ "anyOf": [
+ {
+ "required": [
+ "source_id",
+ "row_count",
+ "rows"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+ ],
+ "properties": {
+ "capability_id": {
+ "type": "string"
+ },
+ "clarification": {
+ "type": "object"
+ },
+ "error": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "details": {
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "retry_hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "filters_applied": {
+ "type": "object"
+ },
+ "guidance": {
+ "type": "object"
+ },
+ "limit": {
+ "type": "integer"
+ },
+ "next_step": {
+ "additionalProperties": true,
+ "properties": {
+ "action": {
+ "type": "string"
+ },
+ "arguments": {
+ "type": "object"
+ },
+ "tool": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "action"
+ ],
+ "type": "object"
+ },
+ "pack_id": {
+ "type": "string"
+ },
+ "provenance": {
+ "type": "object"
+ },
+ "query_mode": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "request_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "row_count": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "rows": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "sort": {
+ "type": "array"
+ },
+ "source_id": {
+ "type": "string"
+ },
+ "truncated": {
+ "type": "boolean"
+ },
+ "warnings": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}search_disaster_links1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": true,
+ "anyOf": [
+ {
+ "required": [
+ "chains",
+ "count"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+ ],
+ "properties": {
+ "chains": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "clarification": {
+ "type": "object"
+ },
+ "count": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "depth": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "error": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "details": {
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "retry_hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "event_id": {
+ "type": "string"
+ },
+ "guidance": {
+ "type": "object"
+ },
+ "links": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "next_step": {
+ "additionalProperties": true,
+ "properties": {
+ "action": {
+ "type": "string"
+ },
+ "arguments": {
+ "type": "object"
+ },
+ "tool": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "action"
+ ],
+ "type": "object"
+ },
+ "provenance": {
+ "type": "object"
+ },
+ "query_event_id": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "related": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "request_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "resolved_event": {
+ "type": "object"
+ },
+ "warnings": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}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."query_dataset1 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_helpsearch_disaster_linksGlobal tsunami events from NOAA NCEI, 2000 BC-present: wave height, runups, and counts.
Global volcanic eruptions from the Smithsonian Global Volcanism Program: VEI, location, dates.
Federal disaster declarations, emergencies, and assistance data
Global earthquake events from the USGS, 2150 BC-present: magnitude, depth, location, counts.
Add one secure layer between your agents and this server.