Get Running Status

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds genuine context beyond that: the data comes from scraping official operator pages, the return is per-route with four discrete status values, and the language may be auto-derived from the operator. No mention of caching, rate limits, or staleness of the live data.

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?

A single dense sentence, front-loaded with the emoji marker and the core purpose, followed by filtering and language behavior. Nothing is redundant, though the density of Japanese clauses makes it slightly harder to scan than a short bulleted form.

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, the description correctly carries the burden of describing the return value (per-route status enumeration) and the optional parameters' fallbacks. It is sufficient to call the tool correctly; only operational details like freshness or error behavior are absent.

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 both parameters are already documented there, including the auto-detect fallback for language and the omit/all convention for operator. The description largely restates this, adding only the example operator keys. Baseline 3 for a fully-covered 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?

States a specific verb and resource ('リアルタイム運行状況検索') plus the exact data source (official pages) and the shape of the result (路線別ステータス with enumerated values). An agent can distinguish this from get_timetable or get_operator_routes, which deal with schedules and route lists rather than live disruption status.

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?

Implies the use case clearly (checking current operational status, optionally scoped by operator), but never names a sibling tool or states when NOT to use it. No guidance on alternatives for schedule lookups vs live status, so routing must be inferred.

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