SeaWeb

get_spot_conditions

Read-onlyIdempotent

Trip-condition board for tracked tourist spots (SF Bay Area, Napa, Monterey/Big Sur): one verdict per spot with per-factor readings.

Factors per spot (only the ones that matter for that place): visibility
(vision-model webcam reading), heat and cold (NWS hourly — outdoor-seating
and heatwave-cancellation bands, freeze flag), wind (nearest NDBC buoy or
forecast — the Big Sur sun-and-wind balance), smoke (EPA AirNow AQI —
wildfire haze), alerts (NWS CAP + advisories), strikes (BART/511), road
(Caltrans closures incl. SR-1/Big Sur).

Pass spot_id (e.g. "golden-gate", "napa", "big-sur") for one spot plus
its `week`: a 7-day forecast outlook per local calendar day (hi/lo °F,
conditions, flags like "extreme heat"/"freezing"/"windy") for picking a
visit day. Week rows are forecast-only; visibility/smoke/alerts are live
signals and appear in `factors`.

Statuses are good|caution|bad|unknown; the spot verdict is the worst
non-unknown factor, and `flagged` names which factor(s) drove it.
"unknown" means that feed is not reporting fresh data — an empty or
stale feed shows unknown, never all-clear. Some cameras are labeled
proxies in `note` (e.g. Alamo Square has no public camera facing the
Painted Ladies). Thresholds documented in gateway/spots.py.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`spot_id`	No

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already mark readOnlyHint and idempotentHint, and the description adds rich behavioral context: status semantics ('unknown' means stale feed, never all-clear), how verdict is computed (worst factor), proxies in notes, and thresholds documented elsewhere. This goes well beyond the annotations.

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

Conciseness4/5

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

The description is long (four paragraphs) but each paragraph serves a purpose: overview, factors, parameter usage, and status semantics. It is front-loaded with a clear summary, though it could be tightened without losing critical detail.

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?

Given no output schema, the description thoroughly explains the output structure: factors, statuses, week forecast, and semantics of 'unknown'. It covers edge cases like proxies and references thresholds in a file, making it complete for an agent to understand the tool's behavior.

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?

Schema coverage is 0%, so the description compensates by explaining spot_id with examples ('golden-gate', 'napa', 'big-sur') and clarifying that it returns a week forecast. However, it does not address the null default or list all valid spot_ids, leaving some ambiguity about optionality and allowed values.

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: 'Trip-condition board for tracked tourist spots' with a verdict and per-factor readings. It lists specific regions and factors, distinguishing it from siblings like get_camera_visibility or get_disruptions. It is specific and unambiguous.

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

Usage Guidelines3/5

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

The description explains how to use it (pass spot_id for one spot) and what data it returns, but does not explicitly state when to use it versus alternatives or provide exclusion conditions. It implies usage for trip planning but lacks explicit guidance on when not to use it.

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

All SeaWeb tools Inspect

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

B3.4/5.0

Disambiguation3/5

There is notable overlap among search, search_web, search_restaurants, and search_salons, as well as between filter_restaurants/filter_salons and search with constraints. However, descriptions clarify the intended vertical or corpus, and entity getters are distinct. The overlap is manageable but could cause misselection.

Naming Consistency4/5

Names mostly follow a get_/list_/search_/register_/delete_/submit_/vote_ pattern in snake_case. Minor deviations like 'recall', 'remember', 'research', and 'travel_health' are less predictable but still readable. Overall consistent and clear.

Tool Count2/5

38 tools is on the heavy side for a single MCP server, exceeding the typical well-scoped range. While the server covers multiple subdomains (search, travel disruptions, memory, feedback, research), the sheer number may overwhelm agents and suggests potential consolidation.

Completeness4/5

The tool surface covers core workflows: search and entity retrieval for restaurants/salons, disruption monitoring with standing queries and webhooks (register/list/delete), research submission/polling, and memory/feedback mechanisms. Minor gaps exist (e.g., no cancel for research jobs, no explicit entity list endpoint), but these are workable and do not break typical agent tasks.

Resources

Need Help?