TidesAtlas

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

With no annotations at all, the description carries the full burden, and it only partially meets it: enumerating the returned fields is valuable given there is no output schema. However, it says nothing about permissions, rate limits, behavior at polar latitudes where sunrise/moonrise may not occur, or what happens when 'port' and 'lat'/'lon' are both supplied or both omitted.

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 front-loaded sentence that spends its words on the enumerated output fields rather than filler. The colon-and-list structure is scannable, though the list is dense and unsorted relative to the time-of-day sequence.

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 5-parameter tool with no annotations and no output schema, the enumeration of return fields compensates reasonably well for the missing output schema. Critical gaps remain around the port-versus-coordinates relationship and edge-case behavior (polar day/night), which an agent would need before calling it confidently.

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%, so the schema already documents each of the five parameters including defaults and the 1-7 day cap. The description adds no meaning beyond that, so the baseline of 3 applies.

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 ('Get') and resource ('sun and moon data') and enumerates the exact fields returned, so an agent knows precisely what this tool delivers. It does not explicitly distinguish itself from siblings such as get_weather or get_tides, leaving differentiation to inference, which keeps it just below a 5.

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?

There is no guidance on when to use this tool versus get_weather, get_conditions, or get_tides, nor on how to choose between the lat/lon pair and the 'port' parameter. All five parameters are optional, and the description offers no hint about which combination is expected.

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

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

No annotations are supplied, so the description carries the full disclosure burden and mostly does not meet it. It says nothing about how the three datasets are merged in the response, what happens if one source is unavailable, whether lat/lon and port are mutually exclusive selectors, or any defaults or limits.

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 short sentences, front-loaded with the capability and followed by the routing rationale. Nothing is padded, though the second sentence is a soft sales claim rather than additional specification.

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 five-parameter aggregation tool with zero required parameters, no annotations and no output schema, the description covers the what but not the how. The unresolved question of when to use lat/lon versus port, and how partial results are returned, leaves real gaps an agent must guess at.

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%, so the baseline applies: lat, lon, days, port and include are already documented in the schema. The description adds no meaning beyond it and notably does not clarify the important lat/lon versus port selection semantics, which the schema also leaves implicit.

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 names a specific verb and a concrete union of resources (weather, marine, astronomy) in a single call, which distinguishes it from the single-domain siblings get_weather, get_marine and get_astronomy. It stops short of naming those siblings by tool name, but the intent is unambiguous.

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?

It explicitly positions itself against the alternative path ('more efficient than calling each separately'), giving the agent a clear selection rule. It omits the reciprocal case, e.g. that if you only need one data type, a dedicated sibling call is cheaper.

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

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

No annotations are provided, so the description must carry the behavioral burden. It usefully discloses asymmetric historical limits: tides up to 365 days but weather only up to 90 days. It does not explain return format, handling of future dates, or other operational constraints.

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?

The description is two short sentences with no wasted words. The core purpose is front-loaded, followed immediately by the key historical range constraints.

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 read-only data retrieval tool with complete schema descriptions, the definition covers the essential historical scope and range limits. It could do slightly more to describe return shape or behavior for invalid past-date requests, but the high schema coverage reduces that need.

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 coverage is 100%, so the schema already documents all four parameters. The description adds meaningful semantics by clarifying that the 365-day limit applies to tides while weather is capped at 90 days, which is not expressed in the schema's generic 'days' maximum.

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 states a specific verb and resource: historical tide predictions and weather data for past dates. It clearly distinguishes itself from current-condition siblings by emphasizing 'historical' and 'past dates', though it does not explicitly name get_tides or get_weather as alternatives.

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?

Usage is implied by 'for past dates', which helps the agent choose this over current-condition tools. However, there is no explicit when-to-use versus when-not-to-use guidance, and no direct routing to siblings such as get_tides or get_weather.

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

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

No annotations exist, so the description bears the full disclosure burden. It does reveal output granularity ("hourly and daily data"), which is genuinely useful, but says nothing about which of lat/lon or port is needed, what happens when neither is supplied, the forecast horizon defaults, data source, or failure behavior for open-ocean coordinates.

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 short sentences, front-loaded with the core purpose and free of filler. It is efficiently written, though the space saved could have been spent on the missing lat/lon versus port disambiguation.

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 four-parameter read tool with no annotations and no output schema, the description covers what data comes back but leaves the calling contract ambiguous. An agent still cannot determine from the definition alone whether it must supply a port slug, coordinates, or both.

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%, so lat, lon, days (1-7, default 3), and port are already documented in the schema. The description adds no additional parameter meaning, such as whether port overrides lat/lon or what units the coordinates use — baseline 3 applies.

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?

"Get ocean and wave forecast" pairs a specific verb with a specific resource, and the parenthetical enumerates the quantities returned (wave height, swell, sea state on Douglas scale). It is clearly distinct from get_tides, get_weather, and get_radar by domain, though the description never explicitly draws that line.

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?

There is no statement of when to reach for this tool versus get_weather, get_tides, get_conditions, or get_observations. It also gives no guidance on choosing between the lat/lon path and the port path, despite zero required parameters making that choice non-obvious.

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

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

With no annotations, the description carries the full load, and it does disclose the 10-minute sampling interval and the single-source, France-only constraint. It omits other behaviorally significant facts: measurement units/datum, data latency or gaps in real-time feeds, and what happens when a non-REFMAR station slug is supplied.

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 tight sentences with no filler. Source and scope come first, then the return cadence, so the most decision-relevant facts are front-loaded.

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 simple three-parameter read tool with no output schema, the description covers source and cadence adequately. However, without an output schema it should at least indicate what a reading contains (timestamp, level, units) since the agent has no other place to learn the return shape.

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%, so the schema already documents date format, the 1-7 day range, and the station-slug requirement. The description only adds the 'French stations only' restriction for port and the 10-minute resolution, which is consistent but marginal beyond the 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 ('Get real-time sea level observations') plus the data source (REFMAR/SHOM tide gauges) and an explicit geographic scope restriction ('French stations only'). It implicitly distinguishes itself from get_tides by emphasizing real-time observations rather than predictions, but never names that sibling, so differentiation must be inferred.

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?

Usage is only implied: 'real-time observations' versus the sibling get_tides suggests measured data now, but the description never says when to choose this over get_tides, get_history, or get_marine. The 'French stations only' caveat usefully rules out non-French ports but is not framed as an explicit selection condition.

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

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

No annotations are supplied, so the description must carry the full behavioral burden. It does disclose the return content (tile URLs) and that frames span past observations plus a short-term nowcast, which is genuinely useful context. It omits auth requirements, coverage area, frame count, tile format, and refresh cadence — gaps that matter for a mapping overlay tool.

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 short sentences with zero filler. What is returned is front-loaded in the first sentence and the frame composition follows immediately.

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 three-parameter, no-annotation, no-output-schema tool, the description covers what goes in and roughly what comes out. It stops short of resolving the coordinates-vs-port choice and gives no sense of the shape or size of the returned frame list, which an agent needs before building an overlay.

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%, so the per-field baseline is 3. But all three parameters are optional and the schema merely says 'Latitude.', 'Longitude.', 'Station slug.' — the description does not explain that a location can be given either by coordinates or by port slug, which is the central ambiguity an agent must resolve.

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 — 'Get rain radar tile URLs' — plus the scope of what the tiles cover (past frames and short-term nowcast frames). This is clearly distinct from sibling tools like get_conditions or get_weather, though the description never explicitly contrasts itself with them.

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 phrase 'for map overlays' implies the intended use case, which is more than nothing. However, there is no explicit when-to-use guidance, no mention of when to prefer get_weather/get_conditions over radar tiles, and no explanation of which parameter combination to choose.

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

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

With no annotations, the description carries the full behavioral burden. It does useful work by disclosing the return shape (datetime, height in meters, high/low type) and dataset breadth (18,400+ stations), but says nothing about station-matching behavior for lat/lon, what happens if both port and coordinates are supplied, rate limits, or error handling for out-of-range inputs.

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?

Three short sentences: purpose first, return values second, coverage last. No filler, and the most important information is front-loaded.

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?

No output schema exists, and the description compensates by describing the returned extremes and units. For a six-parameter read tool with all-optional parameters, the remaining gap is mainly the port-vs-coordinates precedence and station resolution behavior.

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 coverage is 100%, so all six parameters (including the datum enum and 1-14 day cap) are already documented in the schema. The description only restates that port and coordinates are the two location modes, adding no format or precedence detail beyond the 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 ('Get tide predictions') plus the unit of return ('high/low water times and heights') for either a port or coordinates. It clearly separates from get_astronomy/get_weather by naming tides, but never explicitly contrasts with the closest sibling get_marine, which may also touch tidal data.

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?

Usage is only implied by the purpose: call this when you need tide extremes. There is no explicit when-to-use/when-not guidance, no mention that search_ports should be called first to resolve a slug, and no contrast with get_marine or get_astronomy.

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

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

With no annotations, the description carries the full behavioral burden; it usefully discloses that both hourly and daily granularity are returned. It says nothing about precedence or fallback when neither 'port' nor lat/lon is supplied (all four parameters are optional), nor about rate limits, error behavior, or units.

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 short sentences, front-loaded with the action and resource, and the second sentence efficiently covers the return shape. No filler or repetition of the tool name.

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?

The description covers purpose and return granularity, which is reasonable for a read-only lookup with a fully documented schema. It is still incomplete on the ambiguity created by zero required parameters: an agent cannot tell from the text whether port or lat/lon is preferred, nor what the default is if none is provided.

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 coverage is 100%, so the schema already documents lat, lon, days (1-7, default 3) and port slug. The description's 'for a port or coordinates' restates the schema without adding format, precedence, or combination rules. Baseline 3 applies.

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 gives a specific verb and resource ('Get weather forecast') and enumerates the returned quantities (temperature, wind, precipitation, UV, conditions), so the tool's purpose is unambiguous. It does not, however, distinguish itself from siblings such as get_conditions or get_observations, which plausibly overlap with 'forecast' data.

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?

There is no statement of when to pick this tool over get_conditions, get_observations, get_marine, or get_history. The one implicit routing hint, 'for a port or coordinates', is a parameter hint rather than usage guidance and no exclusions are given.

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

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

No annotations are supplied, so the description carries the full burden. It does disclose the important behavioral fact that the result is a complete, bounded enumeration ('all 188 countries') and that returned fields include station counts and ISO codes, implying a safe read. It does not state whether results are static or paginated, nor whether the list reflects only supported regions.

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 sentence with the scope and return fields front-loaded and no wasted wording. Nothing could be removed without losing information.

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 zero-parameter, no-output-schema tool, the description supplies the essentials: what is listed, the count, and the fields returned. The only mild gap is that it does not indicate result format or how the output links to the tides/ports siblings, which matters slightly given there is no output schema.

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?

The input schema has zero properties, so the baseline of 4 applies; there are no parameters whose meaning needs explaining. The description correctly adds that the output carries station counts and ISO codes, which is the only semantic detail that matters here.

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 opens with a specific verb and resource ('List all 188 countries') and scopes it to countries with tide stations, which cleanly separates it from the weather, tides and astronomy siblings. It stops short of explicitly naming a related sibling, but the resource noun alone makes the distinction obvious.

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?

Usage is only implied: the tool is a zero-parameter enumeration, so an agent can infer it is a discovery/lookup step, likely before calling get_tides. There is no explicit statement of when to prefer this over search_ports or get_tides, and no prerequisites or exclusions are given.

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

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

With no annotations, the description carries the full burden. It discloses the returned fields (name, slug, coordinates, timezone, country), which implies a read-only lookup, but says nothing about default result count, ordering, behavior on zero matches, or that partial matching is the search mode.

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 short sentences, front-loaded with the action and followed by the return shape. Nothing is padded, though the return-field list is a slight redundancy with an implicit result contract.

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 simple three-parameter lookup with full schema coverage and no output schema, stating the returned fields makes it callable without ambiguity. The only meaningful gap is not tying the returned slug to the downstream get_* tools.

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 coverage is 100%, so limits, partial-name matching, and country slug format are already documented in the schema. The description only restates the high-level search dimensions (name or country) and adds no format or combination guidance beyond that.

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 names a specific verb and resource ("Search for tide stations") and clarifies that the resource is referred to as a port, which resolves the name/description mismatch. It doesn't explicitly contrast with any sibling, but the search semantics versus the get_* siblings is reasonably self-evident.

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?

Usage is only implied: it is the lookup step before calling get_tides/get_conditions. The description never says when to use this instead of list_countries or that the returned slug feeds the get_* tools, so the agent must infer the workflow.

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