Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DRIP assess the wildfire in Rocky Ridge and generate a situation report"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
AI-powered emergency coordination platform built with NitroStack MCP to accelerate disaster response through intelligent planning, resource orchestration, and real-time operational insights.
DRIP (Disaster Response Intelligence Platform) is an AI-driven emergency response system designed to assist Disaster Management Authorities, Emergency Operations Centers (EOCs), first responders, and relief organizations.
Instead of relying on fragmented information and manual coordination, DRIP orchestrates specialized intelligence modules to:
Assess disaster severity
Analyze environmental conditions
Locate critical resources
Coordinate rescue operations
Generate actionable Situation Reports for decision makers
Built using NitroStack MCP, DRIP exposes intelligent tools that can be orchestrated by AI agents to support emergency response workflows.
Related MCP server: resQ MCP Server
Intelligent incident analysis
Dynamic task selection
LLM-powered Situation Report generation
Minimal task execution strategy
Hallucination-resistant reporting
Provides:
Weather assessment
Hazard analysis
Safe route identification
Nearest hospital discovery
Shelter discovery
Severity estimation
Coordinates operational response:
Incident reporting
Rescue vehicle allocation
Volunteer assignment
Shelter updates
Relief inventory management
Emergency deployment workflow
Automatically generates structured operational reports including:
Executive Summary
Severity Assessment
Affected Area
Threat Analysis
Resource Status
Tactical Action Plan
Intelligence Gaps
Operational Rationale
User Incident
│
▼
Planner Orchestrator
│
┌───────────────┼───────────────┐
▼ ▼ ▼
Intelligence Resources Operations
│ │ │
└───────────────┼───────────────┘
▼
AI Situation ReportNitroStack MCP
TypeScript
Node.js
NitroCloud
Gemini API
Zod
Mapbox (Widgets)
src
│
├── planner/
│ ├── planner.module.ts
│ ├── planner.service.ts
│ └── planner.tasks.ts
│
├── modules/
│ ├── intelligence/
│ ├── operations/
│ ├── resources/
│ └── pizzaz/
│
├── prompts/
│ ├── systemPrompt.ts
│ └── responsePrompt.ts
│
├── services/
│ └── llm.ts
│
└── app.module.tsgit clone https://github.com/nanzz-leo/DRIP.git
cd DRIP
npm install
npm run build
npm run devIncident Report
│
▼
Planner analyzes incident
│
▼
Assess Disaster
│
▼
Locate Resources
│
▼
Plan Rescue
│
▼
Generate AI Situation ReportHuman life first
Verified information only
Zero hallucination policy
Modular AI orchestration
MCP-native architecture
Extensible task-based design
Built during the NitroStack × Amrita University Hackathon.
Locate the nearest available hospital to the specified coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | ||
| longitude | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, placing full burden on description. The phrase 'nearest available' is vague—no explanation of availability criteria, data freshness, or limitations. Lacks details on permissions or side effects.
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 is concise but insufficiently informative for the tool's purpose. Could be expanded without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and minimal param info, the description should clarify expected return (e.g., hospital name, address, distance). Current version is incomplete.
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 0%, and description does not mention latitude/longitude format, ranges, or constraints. Zero added value over 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?
Description clearly states the tool locates the nearest available hospital to given coordinates, with a specific verb and resource. It distinguishes from sibling tools like findNearestShelter or findSafeRoute.
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 guidance on when to use this tool vs alternatives. Lacks context such as 'for medical emergencies' or recommendations to use sibling tools for other needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Locate the nearest emergency shelter to the specified coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | ||
| longitude | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks behavioral details such as output format, whether it's read-only, or any restrictions.
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 is concise and front-loaded with the key action, no unnecessary words.
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 two-parameter tool, the description is too minimal; lacks information about output, possible empty results, or error handling, especially given no output schema.
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 has no property descriptions (0% coverage) and the tool description does not elaborate on latitude/longitude format or constraints.
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 locates the nearest emergency shelter using coordinates, which distinguishes it from sibling tools like findNearestHospital or findSafeRoute.
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 guidance on when to use this tool versus alternatives such as findNearestHospital or findSafeRoute; no context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the safest available route between two geographic coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| startLatitude | Yes | ||
| startLongitude | Yes | ||
| destinationLatitude | Yes | ||
| destinationLongitude | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral implications. It mentions 'safest' but does not define what safety means (e.g., crime data, road conditions). Does not indicate return format, limitations, or required privileges.
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, concise sentence with no extraneous information. It is appropriately front-loaded and efficient.
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 4 required numeric parameters, no output schema, and no annotations, the description is too minimal. It lacks information about return values, error cases, and how 'safest' is determined, making it incomplete for an agent to use confidently.
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 0% and the description adds no parameter details beyond what parameter names imply. It does not explain coordinate ranges, format (e.g., decimal degrees), or any constraints.
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 finds the safest route between two geographic coordinates. It uses a specific verb ('find') and resource ('safest available route'), and the purpose is distinct from siblings like findNearestHospital or geocodeLocation.
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 guidance provided on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description merely states the function without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a location name or address into geographic coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fails to disclose behavioral traits such as coordinate system, accuracy, or output format. It only states the basic conversion, leaving major 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?
Single sentence, no redundancy. Efficiently states core purpose, though additional detail would improve without harming 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 no output schema, the description should describe return format (e.g., lat/lng coordinates). It omits this, leaving agents unsure of the output. Incomplete for effective tool 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 coverage is 0%, and the description does not explain the 'location' parameter beyond its name and type. Adding 'name or address' provides minimal semantics but insufficient detail for correct usage.
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 converts a location name or address into geographic coordinates, specifying the verb 'convert' and resources. It distinguishes from siblings focused on finding nearest places.
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 guidance on when to use this tool vs alternatives. While sibling names imply distinct purposes, the description itself offers no usage context or exclusions.
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.
v1.0.0findNearestHospitalfindNearestShelterfindSafeRoutegeocodeLocationEach tool has a clearly distinct purpose: locating hospitals, locating shelters, finding safe routes, and geocoding. No two tools overlap in function; even the two 'nearest' tools target different types of facilities.
All tool names follow a consistent verb_noun pattern using camelCase (findNearestX, geocodeLocation). The naming is predictable and readable.
Four tools is a reasonable number for a focused emergency response server. Each tool earns its place without being excessive or insufficient.
The tool set covers the core emergency location needs: finding hospitals, shelters, safe routes, and geocoding. Minor gaps may exist (e.g., getting detailed info on a facility), but the surface is largely complete for its stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP Hub: AI service discovery, per-user OAuth, and multi-service workflow orchestration
AI-powered incident management and server monitoring via MCP.
An AI concierge that turns static forms into adaptive AI conversations. From any MCP client.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nanzz-leo/DRIP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
