Skip to main content
Glama
Sign In

Vedar — Kamchatka travel

by ru.vedarai
OverviewDiscussionsAdmin

Regional safety status

safety_status
Read-onlyIdempotent

Kamchatka regional safety status: active alerts (seismic, volcanic, weather, MChS) with their source and dates, plus elevated volcanoes (KVERT, KB GS RAS). Текущая обстановка по Камчатскому краю целиком: активные предупреждения, их количество и тяжесть, у каждого пункта ленты — когда он появился и до какого числа стоит в ленте, вулканы с повышенной активностью (KVERT, КФ ЕГС — отдельная шкала), свежесть данных и источник верхнего предупреждения (ленты: КБГС РАН и ЕГС РАН — сейсмика, USGS, МЧС по Камчатскому краю, Росгидромет — погода, NASA FIRMS — пожары). Используй, когда спрашивают, безопасно ли сейчас ехать или что происходит в крае. Для конкретного места используй get_guardian_context.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "safety_status"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already mark it read-only, idempotent, non-destructive, and closed-world. The description adds valuable context: the feeds queried (KB GS RAS, EGS RAS, USGS, MChS, Roshydromet, NASA FIRMS), that volcano activity uses a separate scale, and that data freshness and the source of the top alert are included. Return format is not described, but no output schema exists.

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

Conciseness2/5

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

The description is two long sentences per language (English and Russian), largely duplicated content. The when-to-use guidance arrives last. Much of the feed list could be trimmed; the duplication makes it bloated and back-loaded.

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

Completeness3/5

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

Covers purpose and when to use, but with no output schema the agent does not know the shape of the response (fields, alert object structure, timestamps). For a status tool an agent will call and parse, a brief mention of the return shape would complete it.

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

Parameters4/5

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

Zero parameters, so the schema imposes no burden and the baseline is 4. Nothing in the description misleads about inputs.

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

Purpose4/5

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

The description states a specific resource (regional safety status for Kamchatka) and enumerates its contents: active alerts, elevated volcanoes, data freshness, sources. It distinguishes itself from get_guardian_context for place-specific queries. It is clear but longer than needed and mixes languages.

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

Usage Guidelines5/5

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

Explicitly says when to use it ('ask if it's safe to travel now or what's happening in the region') and names the alternative ('For a specific place use get_guardian_context').

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

All Vedar — Kamchatka travel toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources