Skip to main content
Glama

DaedalMap Tsunami Data

by com.daedalmap

Get Tool Help

get_tool_help
Read-only

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tool_nameYesExact tool name from tools/list.

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description reveals the tool returns refusals, access limits, provenance fields, and a shared interaction contract. This provides substantial insight into the tool's behavior and the nature of its responses.

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

Conciseness5/5

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

The description is two sentences with no filler. It front-loads the purpose, then lists specific output types and usage instructions, achieving maximum information density.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with readOnlyHint and no output schema, the description covers purpose, usage context, input source, and the types of information returned. It is comprehensive and leaves no critical gaps.

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

Parameters3/5

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

The input schema already fully documents the sole parameter, tool_name, specifying it must be an exact name from tools/list. The description reinforces this workflow but adds no additional semantic detail beyond what the schema already covers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: providing guidance for using another tool on the MCP facade. It enumerates specific outputs (when to use, refusals, example, limits, etc.), making it distinct from sibling data-access tools.

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

Usage Guidelines4/5

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

The description provides explicit usage guidance: call this before working with an unfamiliar tool, and use tools/list to discover tool names. It lacks an explicit statement of when not to use it, but the context strongly implies it is only for unfamiliar tools.

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

All DaedalMap Tsunami Data toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation3/5

get_disaster_link_chain and get_disaster_links_for_event both require an exact event ID and return related-disaster information, with only subtle differences in output (chain vs. links). The discovery tools are distinct, but these two overlap enough to cause an agent to pick the wrong one.

Naming Consistency4/5

Tool names mostly follow a consistent get_<object> snake_case pattern, with clear verbs and objects. The single deviation is search_disaster_links, but it still fits the overall naming style and is predictable.

Tool Count5/5

7 tools is well-scoped for a specialized data server, covering discovery (catalog, pack, tool help), core querying (tsunami_events), and linked-disaster navigation. Each tool earns a place without feeling excessive.

Completeness4/5

The server covers its domain well: tool discovery, pack metadata, help, tsunami event queries, and disaster-link exploration. Minor gaps exist (e.g., no direct tool for other pack data, no event count by ID), but agents can work around these using get_tsunami_events and filters.

Resources