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

No annotations are provided, so the description carries the full burden and does well: it discloses the disk cache ('only fetches new tours from the API'), the cache-busting flag, the save location and its default resolution, and the composition guarantee of saved paths plus OSRM connectors. It stops short of auth requirements, rate limits, runtime cost, and whether an existing file at save_path is overwritten.

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?

Front-loaded with the purpose, then mechanism, then mode selection, then args — a sensible hierarchy with no filler sentences. Minor redundancy: the loop/point-to-point rule appears both in prose and again in the end_lat/end_lon entries.

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 an 11-parameter tool with an output schema present, the description covers purpose, mode branching, caching, and every argument, so an agent can invoke it correctly. Remaining gaps are operational: prerequisite credentials/auth, failure behavior on bad tour_ids, and expected runtime are unaddressed.

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 0%, so the description must compensate, and it does: all 11 parameters are documented in the Args block with semantics and defaults that match the schema (distance_km=50, min_gravel_pct=60, use_saved_highlights=True, force_refresh=False). It also links two params ('route_name' feeds the 'save_path' default) and clarifies the null-default end_lat/end_lon.

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+resource ('Build a custom gravel route by combining segments from saved tours') and immediately explains the mechanism: corridor selection, progress ordering, OSRM connectors. None of the sibling tools build routes, and the description makes the output object (a GPX combined route) 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?

Gives explicit conditional guidance for the loop vs point-to-point modes ('omit end_lat/end_lon' vs 'provide both'), which is the main branching decision an agent must make. It also explains when to set force_refresh. It does not, however, route the agent against alternatives (e.g., when to prefer download_tour_gpx or get_tour_segments instead).

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, but it does disclose a genuinely useful behavioral trait: the tool's mode switches based on save_path (filesystem write vs. returning GPX XML text). It omits whether credentials are required (a sibling setup_credentials exists), what happens on invalid tour_id, and any file-overwrite behavior.

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 lines, the core action front-loaded, followed by a compact Args block. No filler or redundancy.

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 two-parameter download tool with an output schema present, the description covers purpose, both parameters, and the return-mode behavior. The main gap is the absence of any prerequisite/permission context given setup_credentials exists among siblings.

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 0%, so the description must compensate, and it does: tour_id is defined as 'the Komoot tour ID' and save_path is explained as an optional path whose emptiness changes the return behavior. This adds real meaning beyond the bare integer/string types.

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+resource ('Download a Komoot tour as GPX file') with a clear output format, which cleanly separates it from the inverse sibling upload_gpx_to_komoot. It does not, however, explicitly name alternatives or scope (e.g., single tour vs. combined route), so it stops short of 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 siblings like list_tours, get_tour_details, or build_combined_route. It vaguely implies you need a tour_id, but no preconditions (credentials, tour existence) or exclusions are stated.

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 carries the full behavioral burden. It discloses the nature of the returned content but says nothing about result limits, pagination, auth requirements, or how many highlights come back. For a no-annotation tool this leaves meaningful behavioral gaps.

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 well-formed sentences plus an Args block, front-loaded with the core purpose before the content explanation. Appropriately sized with no filler.

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?

An output schema exists, so return values need no explanation. Parameters are documented and the purpose is clear for a read-style lookup tool. The main omission is the lack of differentiation from the saved-highlights sibling, which is a minor completeness gap.

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 0%, so the description must compensate, and it does: it defines lat/lon as the center point and radius_m as the search radius in meters. This adds real meaning over the bare schema titles, though the 5000 default merely repeats 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?

The description opens with a specific verb+resource ('Get highlights and points of interest near a location') and further qualifies the content type (scenic viewpoints, interesting places, user-recommended spots). It is clear what the tool does, but it never distinguishes itself from the sibling get_saved_highlights, so it falls short of the top tier.

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 by stating the highlights are 'useful for planning attractive gravel routes', which gives an agent a sense of when the tool fits. However, it names no alternatives and gives no when-not-to-use guidance, leaving the distinction from get_saved_highlights entirely to inference.

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 carries full behavioral burden. It discloses the semantic role of the returned data (waypoint attractors the route combiner prefers), which is useful, but says nothing about authentication needs, rate limits, or whether the saved set can be empty.

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 compact lines, front-loaded with the action and resource, then the purpose. Minor duplication of 'saved/bookmarked' does not cost meaningful space.

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 an output schema present, return-value explanation is unnecessary, and with zero parameters there is no input contract to document. The description supplies the one thing structured fields cannot: why the agent should care about this data.

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 tool takes zero parameters, so there are no parameter semantics to explain; baseline 4 applies by the rubric.

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 ('Get') and resource ('your saved/bookmarked Komoot highlights') and clarifies the ownership scope ('personally saved'). This distinguishes it from the sibling get_highlights, which presumably returns highlights generally rather than the user's saved set.

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 explains the downstream purpose — these highlights act as waypoint attractors in combined-route building — which implies when the agent would care about them. However, it never explicitly contrasts this tool with the sibling get_highlights, so the routing decision is left partly to inference.

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 disclosure burden. It does usefully explain that include_coordinates can return 1000+ points and defaults to False to keep responses compact, but says nothing about authentication requirements, failure modes for invalid tour IDs, or whether the call works across all tour types.

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?

Front-loaded with the core purpose, followed by a scoped elaboration and a clean Args block; every element is relevant. There is mild repetition between the opening line and the second paragraph about surface/way types.

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?

An output schema exists, so return values need not be documented, and the description still summarizes the key returned data. For a two-parameter read tool this is nearly complete; only auth/error behavior is absent, which is a minor gap.

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 0%, so the description must compensate, and it does: tour_id is identified as the Komoot tour ID and include_coordinates is explained with its default, its payload size, and the reason for the default. Only tour_id's type/format nuance is left 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?

Names a specific verb and resource ('Get full details of a Komoot tour') and enumerates the distinctive payload (surface types, way types), which separates it from siblings like get_tour_segments or download_tour_gpx. It stops short of explicitly naming those siblings as alternatives, so it is clear but not fully differentiated.

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?

Offers a use context ('essential for gravel ride planning') that implies when the tool matters, but gives no when-not guidance and never points to the sibling tools an agent should prefer for GPX download or segment data. Usage is implied rather than stated.

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, and it does disclose that the output is raw unaggregated arrays rather than summarized data. However, it says nothing about response size, pagination, rate limits, or that the operation is a non-destructive read, leaving the safety profile implicit.

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 core purpose and sibling contrast are front-loaded in the first two sentences with no filler. The trailing Args block is somewhat formulaic for a single self-evident parameter, but it is short and does not bury the main point.

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?

An output schema exists, so the description need not enumerate return fields, and it correctly focuses on purpose, differentiation, and the one input. It is nearly complete for a single-parameter read tool; only the absence of any safety/pagination note keeps it from the top score.

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 0%, so the description must compensate; it supplies the one parameter description ('The Komoot tour ID'), which adds the Komoot-domain context missing from the bare 'Tour Id' title. That is the minimum needed but adds no format, range, or lookup guidance.

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 ('Get raw segment data') and enumerates exactly what the payload contains (coordinates, surfaces, way types). It explicitly distinguishes itself from the sibling get_tour_details by contrasting raw segment arrays against aggregated surface 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?

It names the alternative tool and the condition that selects this one: use this for route combination work (splitting tours by surface type, recombining gravel segments) rather than for aggregate surface stats. It gives clear context but never states an explicit exclusion or prerequisite, so it falls just short of the top band.

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 carries the full behavioral burden. It signals a read/list operation and notes that limit is the max number of tours to return, but omits authentication requirements, pagination behavior, sort order, and whether filters combine.

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 front-loaded with the purpose, then uses a compact Args list for parameter details. Every sentence contributes either usage or parameter meaning, with no filler or repetition beyond useful clarification.

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 all parameters and the output schema handles return values, which is helpful. With no annotations and six optional parameters, however, missing auth expectations, pagination behavior, and read-only confirmation leave some gaps for correct invocation.

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 0%, so the description must compensate, and it documents all six parameters. It adds useful examples for sport_type and tour_type and explains the relationship between near_lat, near_lon, and radius_km, though it does not restate schema defaults.

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 the specific verb 'List' and resource 'Komoot tours', with optional filters, so the core operation is clear. It does not explicitly distinguish this tool from siblings such as get_tour_details, but the listing purpose is unmistakable from the name and description.

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?

Provides practical filtering guidance, including how to use near_lat/near_lon for geographic search and radius_km with them. However, it does not say when to choose this tool over alternatives like get_tour_details or get_highlights, leaving usage context largely implied.

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 provided, the description carries the full behavioral burden and does well: it discloses that credentials are verified before storage, the keychain service name ('komoot-mcp'), and the failure semantics ('a failed sign-in stores nothing'). It stops short of covering overwrite behavior, keychain access requirements, or security handling of the plaintext password.

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, front-loaded with the action, then the ordering/prerequisite, then the failure guarantee. Every sentence carries distinct information with no filler.

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?

An output schema exists, so return values need not be described. For a credential-setup tool the description covers the prerequisite timing, the alternative configuration path, storage location, and failure behavior - all that an agent needs to invoke it correctly.

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 0%, but the two parameters are self-evident (email, password) and the description ties them to the env-var equivalents KOMOOT_EMAIL/KOMOOT_PASSWORD, which clarifies their meaning. It still adds no format, validation, or constraint detail beyond the obvious.

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 (store) and resource (Komoot credentials in the system keychain), with scope ('for future use') that immediately separates it from the tour/highlight/route siblings. An agent can tell this is the one-time auth setup tool without opening the schema.

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?

Explicitly says 'Call this once before using any other Komoot tools' and names the alternative path (KOMOOT_EMAIL and KOMOOT_PASSWORD environment variables). This is exactly the when-to-use / when-not-to-use / alternative structure that removes inference.

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 disclose the side effect of creating a new tour, but says nothing about required credentials, permission needs, rate limits, duplicate-name handling, or failure behavior. Significant gaps for a mutation 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?

Front-loaded with the action, followed by a compact per-argument breakdown. The 'Args:' block is slightly mechanical but every line earns its place by documenting an otherwise undescribed parameter.

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 output schema exists, so return values need not be explained, and all three parameters are covered. However, for a mutating upload tool with no annotations, the missing authentication/prerequisite and error-handling context leaves the definition only minimally sufficient.

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 0%, so the description must compensate, and it largely does: it defines gpx_path as the file to upload, name as the tour name, and sport with concrete common values (touringbicycle, mtb, racebike). Only the default value and full acceptance set of sport remain undocumented.

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, resource and outcome: uploading a GPX file as a new planned tour on Komoot. This is clearly distinguishable from the download_tour_gpx sibling by the verb alone, though the description never explicitly names or contrasts the sibling. Clear but no explicit differentiation.

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?

No when-to-use, when-not-to-use, or alternative guidance is provided. The presence of setup_credentials as a sibling suggests an authentication precondition that the description never mentions. Usage must be fully inferred from the name.

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