storm_detailsFull details for one active storm by id (e.g. "al052026") or name (e.g. "Douglas"), including all advisory/forecast/cone/surge product links. Keyless.
| Name | Required | Description | Default |
|---|---|---|---|
| storm | Yes | Storm id or name. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / examplesAdded value: +[
+ {
+ "storm": "al052026"
+ },
+ {
+ "storm": "Douglas"
+ }
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, etc., covering safety. The description adds that it is 'Keyless' (no API key required) and details the product links included, providing additional context beyond 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?
Two sentences with no wasted words. The purpose is front-loaded with the key verb and resource, followed by specifics and the keyless note.
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, full schema coverage, and comprehensive annotations, the description covers all necessary context: what it does, how to specify the storm, what data is returned, and authentication status.
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%. The description adds value by providing explicit examples ('al052026', 'Douglas') inline, clarifying the parameter format beyond the schema's short description.
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 ('Full details for one active storm') and clearly identifies the resource (storm by id or name), with examples of id format and name. It distinguishes from sibling 'active_storms' which lists storms.
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 usage when complete details on a specific storm are needed, but does not explicitly state when not to use or mention alternatives beyond the implicit contrast with 'active_storms'. Still clear enough for effective selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have distinct purposes with clear descriptions, but ask_pipeworx_beta is nearly identical to ask_pipeworx, and the presence of several meta-tools may cause slight confusion. Overall, an agent can differentiate most tools.
Tool names consistently use lowercase_with_underscores and follow an action_domain pattern (e.g., validate_claim, scan_competitor_ai_presence). There is a mix of verb-noun and noun-verb, but the pattern is predictable and readable.
33 tools is on the higher end, but given the broad scope (finance, drugs, prediction markets, data retrieval, memory), the count is reasonable. However, the server name 'Hurricanes' suggests a narrower focus, making the count feel excessive for that domain.
The tool set covers a wide range of data domains and includes meta-tools for discovery, grounded answers, and subscriptions. Minor gaps exist (e.g., no non-US company data), but overall the surface is comprehensive for a general-purpose data server.