Adrenaline List

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds useful context by naming the kind of data returned (requirements, review summary, operator contact) and clarifying that only published adventures are exposed on the public page.

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 a single well-formed sentence with no filler. The core operation and scope are front-loaded, and every clause contributes useful 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 simple read-only lookup with one required parameter and annotations covering safety, the description is largely complete: it names the resource, identifier, visibility constraint, and returned fields. It does not mention error behavior for missing or unpublished slugs, 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%, but the single parameter has a pattern constraint in the schema. The description adds that the slug identifies one published adventure, which is helpful, but it does not explain slug format or where to obtain one beyond the schema's pattern.

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 uses a specific verb and resource ('Get full public details for one published adventure') and scopes it to a single item retrieved by slug. This clearly distinguishes it from sibling tools like search_adventures and list_rankings, which operate on collections.

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 one published adventure by slug' implies when to use it (after obtaining a slug, for a single item), but there is no explicit guidance on when to prefer this over search_adventures or other siblings. No exclusions or prerequisites 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds two things the annotations cannot: the sign-in requirement and the conditional behavior that the profile URL is only present when the member has a public profile with a username — genuinely useful call-time context.

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?

One sentence carries the resource, the full metric list, the conditional profile URL, and the auth prerequisite. Nothing is redundant and the most important content (the stats) 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?

With no output schema, the description carries the burden of describing return values and does so explicitly, field by field. The main residual gap is error/unauthenticated behavior, which is implied by "Requires sign-in" but not stated.

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 is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly avoids inventing parameter-like inputs.

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 resource (the signed-in member's Adrenaline List stats) and enumerates the exact metrics returned — adventures done, bucket list size, countries visited, profile URL — which cleanly separates it from siblings like list_my_adventures or get_adventure. It stops short of explicitly naming an alternative, so the differentiation is implicit rather than spelled out.

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?

"Requires sign-in" is a useful prerequisite, but the description never states when to reach for this versus list_my_adventures or list_rankings. Usage is only inferable from the returned-field list; no exclusions or alternative routing 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?

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description still adds real context beyond them: it requires sign-in, returns 50 items per page, and lists exactly which fields come back.

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-pair with the identity and scope front-loaded and no filler. The returned-field list is long but earns its place since there is no output schema.

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 usefully enumerates returned fields, and it covers auth and pagination for a two-parameter read tool. Only the semantics of the page parameter remain underspecified.

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 0%, so the description carries the burden, and it explains the status enum values and page size (50 per page). It does not clarify the page parameter itself beyond pagination implication, leaving one of two parameters thinly documented.

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 the signed-in member's own adventures') and enumerates the returned fields, so scope is unambiguous. The word 'own' implicitly contrasts with search_adventures, but no sibling is named explicitly.

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?

'Filter by status (done or bucket_list)' implies the intended use, and 'Requires sign-in' sets a precondition. It never states when to prefer this over search_adventures or get_adventure, nor any exclusions.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context by explaining what each ranking metric means and that only published adventures are returned with their score, though it does not discuss pagination or rate 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?

The description is compact and front-loaded, defining the resource first and then the ranking types. It is dense but every clause contributes meaning; the sentence is long but not padded.

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 listing tool with annotations covering safety and no output schema, the description is mostly complete. It explains ranking semantics and the returned data, but omits any mention of the limit parameter or result ordering beyond the ranking definition.

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 carry parameter meaning. It does this well for the required list parameter by defining each enum value's scoring methodology, but it does not mention the optional limit parameter, leaving its behavior to the schema defaults and bounds.

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 resource (Adrenaline List's own ranking lists) and enumerates the five list types with their scoring basis. It implicitly distinguishes from search siblings by emphasizing "own ranking lists," though it does not explicitly name an alternative.

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: the tool is for retrieving Adrenaline List's curated rankings. However, there is no explicit when-to-use guidance, no when-not-to-use guidance, and no mention of the sibling tools search_adventures or get_adventure as alternatives.

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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds one useful behavioral detail — counts are of *published* activities, implying unpublished/zero-activity options may be absent — but says nothing about result size, ordering, or how the two lists are shaped.

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 zero filler, front-loading what is returned and ending with the sibling it pairs with. Nothing to trim.

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 and 0% parameter documentation, the description should say more about the response shape (are results grouped, keyed by slug, sorted by count?) and what the limits do. It covers purpose and pairing well but leaves the return contract thin.

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% and the description never mentions categories_limit or destinations_limit. The only hint is the implicit 'counts/limits' framing; the agent gets no explanation of what these caps truncate or whether hitting them silently drops options.

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 (list) and precisely names the two resources returned: destination (country) slugs and category slugs, plus activity counts. This is clearly distinguishable from get_adventure, list_rankings, and search_adventures.

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?

"for use with search_adventures" explicitly routes the agent: this tool is the enumeration step that supplies valid slugs to the search tool. It stops short of stating when not to use it or whether calling search_adventures with free text is a valid alternative.

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?

Goes well beyond the annotations by disclosing upsert/merge semantics: anything omitted keeps its stored value, with stated defaults (public visibility for a new entry) and the rule that the completion date is preserved. That is exactly the non-obvious mutation behavior an agent needs and annotations cannot convey.

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-loads the action and packs several useful clauses into a compact block with no filler. The trailing 'Requires sign-in' sentence is slightly detached but still earns its place.

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 mutation tool with no output schema and five parameters, the definition covers prerequisites, defaults, merge behavior, and idempotency, leaving nothing material for an agent to guess before calling it.

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 carry the load; it does, explaining slug provenance, what notes/completed_at/visibility mean, defaults, and the status options in prose. Only the slug's allow/format constraint is left to the schema pattern.

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?

Opens with a specific verb+resource ('Add a published adventure ... to the signed-in member's bucket list or mark it as done') and scopes it by slug sourced from search_adventures. An agent can distinguish this from search_adventures and unmark_adventure without inspecting 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?

States the sign-in prerequisite, where slugs come from, and covers the repeat-call case. It stops short of explicitly naming unmark_adventure as the way to remove an entry, so the when-not guidance 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?

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, lowering the bar. The description adds two useful facts beyond that: only published activities are searched, and prices are indicative. It omits pagination behavior despite page/page_size params and gives no hint at result ordering or shape.

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 sentences, no waste: the search scope and filters come first and the sibling pointer follows. The trailing price caveat is short and earns its place by warning about data quality.

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 and nine optional parameters, the description should say more about what results look like and how pagination works (page max 50, page_size max 20). It covers the filtering surface but leaves the return shape and paging behavior to be discovered by the agent.

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 is expected to carry parameters. It maps most filters (text, destination slug, category slug, adrenaline rating range, months, maximum duration), but page and page_size are never mentioned, and the min/max boundaries on adrenaline are not explained beyond a redundant (1-10) note already in 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 (Search) and resource (published adrenaline activities on Adrenaline List), plus the filter dimensions it supports. It doesn't explicitly contrast with get_adventure or list_rankings, but the singular-vs-search distinction against siblings is reasonably inferable.

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?

"Use list_search_options for valid slugs" is an explicit pointer to a sibling tool and a prerequisite for correct slug values. It stops short of saying when to prefer get_adventure or list_rankings, so there is no true when-not-to-use guidance.

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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered; the description adds value by spelling out the no-op case ('changes nothing') and that unpublished adventures can still be removed, and by flagging the sign-in requirement. It does not describe the response on success, but the mutation semantics are well disclosed.

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, zero padding, with the action and scope front-loaded and the edge-case behavior following. Every sentence earns its place.

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 single-parameter mutation with no output schema, it covers auth, target lists, unpublished-adventure handling, and the no-op case. The only gap is what the caller gets back on success, which is minor for an idempotent removal.

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 carries the burden; it at least identifies the parameter as a slug, tying it to the identifier used by the other adventure tools. It does not reveal the expected format (lowercase alphanumerics with hyphens per the pattern) or how to obtain a slug, leaving the schema's regex as the only format 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?

States a specific verb (Remove) plus the exact resource (an adventure) and the two containers it can be removed from (bucket list or done list), keyed by slug. It is trivially distinguishable from mark_adventure, its inverse, and from the read-only list/search siblings.

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 concrete conditions: works even for an adventure that is no longer published, and is a no-op if the adventure is on neither list. It also states the sign-in prerequisite. It does not name mark_adventure as the counterpart, but there is no genuine ambiguity about which sibling to choose.

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