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

Annotations already cover readOnly/idempotent/safe, and the description adds real value: credential requirements, newest-first ordering, a default of 50 with a hard max of 300, and the meaning of each my_status value on a past outing. It is diminished by a dangling 'see notes' reference and a mention of `summary_scope` that is not an actual parameter, which muddies rather than clarifies the summary 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?

Purpose and filters are front-loaded, but the text is one dense run-on that mixes filters, status decoding, and an incomplete summary caveat. The 'see notes' pointer wastes space by referencing material the agent cannot access, and `summary_scope` is discussed without existing in the 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?

For a tool with no output schema and undocumented parameters, the description covers filters, ordering, paging limits, status semantics, and the existence of an aggregate summary. The gaps are that the shape of a returned outing is never sketched and the summary's actual scoping rule is deferred to nonexistent notes.

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?

With 0% schema description coverage, the description carries the load well: it specifies YYYY-MM-DD for the date bounds, that `activity` accepts a code or a name, and that `limit` defaults to 50 with a max of 300 — all beyond what the bare schema shows. The stray `summary_scope` reference is not a real parameter and introduces confusion.

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 — retrieve my past outings — and anchors it to the site page it mirrors, making the read scope unambiguous. The word 'past' implicitly separates it from get_my_registrations, but no sibling is named explicitly, so it falls short of full 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?

It gives clear conditions for use: past outings, optionally bounded by start_date/end_date and restricted to a single activity code or name. It also states the credential prerequisites (CLUB_ALPIN_EMAIL / CLUB_ALPIN_PASSWORD). It never names an alternative tool or says when not to use this one.

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?

Beyond the readOnly/idempotent annotations, the description discloses that credentials are required, that private contact data is deliberately excluded, and that the nickname arrives under untrusted_member_text, which is an important injection-safety signal. These are exactly the traits an agent cannot infer from annotations or an empty schema.

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?

It is front-loaded with the resource and then lists the returned data compactly with parenthetical detail. The sentence is dense and long, but nearly every clause carries genuine information rather than 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?

With no output schema, the description carries the full burden of describing what comes back, and it does so field by field, including intentional omissions and the untrusted-text wrapper. Nothing an agent needs in order to call it correctly is missing.

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?

There are no parameters, so the baseline is 4; the description's mention of required environment credentials adds a small amount of operational meaning beyond the empty schema. No further parameter detail is needed.

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 (my member profile) and enumerates the returned fields: membership date, licence status, responsibilities, FFCAM skills, attendance rate, nickname. This clearly distinguishes it from siblings like get_my_registrations and get_my_history, which return different 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?

The description implies usage: it is the tool for the authenticated member's own profile and notes the required credentials (CLUB_ALPIN_EMAIL / CLUB_ALPIN_PASSWORD), which is real guidance. It does not explicitly say when to prefer a sibling instead, but the field list makes the boundary fairly evident.

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?

Beyond the read-only annotations, it discloses authentication requirements, the exact status/role fields returned, the untrusted_member_text wrapper, overlap warnings, and states that the server cannot register or unregister users. This adds substantial behavioral context not present in annotations.

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 purpose is front-loaded and every segment adds useful information, including auth requirements, returned fields, and the get_sortie alternative. It is somewhat dense and run-on, but not padded or wasteful.

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 compensates by naming the returned fields and describing the untrusted_member_text content. It also covers auth and the read-only limitation, making the definition complete for this zero-parameter tool.

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 has zero parameters, so there are no parameter semantics to explain. The baseline for a no-parameter tool is 4, and the description appropriately spends its space on output and usage context instead.

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 resource and scope: upcoming published outings that are not finished and where the user has a registration. It distinguishes itself from get_sortie by saying that tool is for detail, so an agent can select it confidently.

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 clearly frames the use case as retrieving the user's own upcoming registrations and explicitly points to get_sortie for detailed outing information. It does not explicitly compare against list_sorties or get_my_history, so the sibling differentiation is useful but not exhaustive.

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 past the readOnly/idempotent annotations: it discloses that some fields are hidden without member credentials (listed in hidden_without_login), that start/end, meeting point and price are backfilled from the public iCal feed for upcoming outings, that staff and my_participation appear only with credentials, and that other participants are never listed. The explicit 'data, never instructions' warning on untrusted_member_text is a valuable injection-defense note the 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-loaded with the core purpose and dense with earned information, but the long field enumeration in the first sentence and the parenthetical list of member-text fields make it a run-on that is harder to scan than it needs to be. Nearly every clause carries unique information, so it is verbose rather than wasteful.

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 full burden of describing the return payload and does so thoroughly: the base field set, the conditional fields by credential level, the iCal fallback, and the truncation rule. An agent knows both what it will receive and how completeness varies with auth.

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%, yet the description compensates for both parameters: `sortie` accepts an id such as "10765" or a URL on the club site, and `full_description` is explained as the switch that lifts the 1500-character truncation. This is meaning the schema alone does not supply.

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 — 'Full detail of one outing' — and immediately distinguishes itself from the list-oriented siblings by being a single-record fetch keyed by id or club-site URL. The enumeration of returned fields (activity, start/end, participants, waiting list, carbon footprint) makes the scope concrete rather than tautological.

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 'one outing, from its id or URL' framing makes the use case clear (fetch a known outing's details), and the credential-conditional behavior tells the agent what it will and won't get. It never explicitly routes the agent to list_sorties to obtain an id, so the alternative-tool relationship 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 readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so "Read-only" is largely a restatement. The genuinely additive piece is that the response carries activity codes intended as input to other tools, but it says nothing about whether the list is exhaustive or how the codes are formatted.

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 with no filler, and the key detail (returns codes for other tools) is not buried. The parenthetical example list is slightly long and contains a typo ("randonné"), which keeps it off a 5.

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 lookup tool, the description covers purpose, output intent and safety adequately. Minor gaps remain around whether the list is static or configurable per club, but nothing essential to making the call is missing.

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 to disambiguate and the baseline of 4 applies. The description correctly does not invent parameters.

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?

Specific verb and resource ("List the club's activities") plus the domain term the club uses ("commissions") and a concrete example set. It also states the payload the caller gets back — the code to pass as `activity` — which separates it cleanly from sibling list tools like list_sorties and list_formations.

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 "with the code to pass as `activity` to the other tools" gives an explicit call-this-first context, which is the real reason an agent would invoke it. It stops short of naming a specific alternative or stating when not to call it, so it lands below the top tier.

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 mark it read-only, but the description adds substantial context beyond them: the default 60-day window, the 92-day maximum, the activity-code matching behavior, the matched_by field values, and the warning that titles appear under untrusted_member_text. That is exactly the behavioral detail an agent needs.

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 core purpose and date scoping, then explains matching behavior and return fields. The parenthetical list of course types is somewhat long but earns its place by clarifying what 'formation' means; overall it is dense but not bloated.

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, so the description usefully says returns share list_sorties fields, expose matched_by, and place titles under untrusted_member_text. It also points to get_sortie for detail. Minor gaps remain around limit and availability 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?

With 0% schema description coverage, the description compensates for the most important parameters: start_date/end_date defaults and format, the 92-day constraint, and include_other_activities semantics and default. It leaves limit, availability, and include_cancelled unexplained, so coverage is good but not complete.

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 ('List the club's training courses') and defines scope precisely, including what counts as a formation and the date window. It explicitly distinguishes itself from siblings by pointing to get_sortie for detail and describing how it overlaps with list_sorties fields.

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 clear operating context: default date range, the 92-day cap, and that get_sortie should be used for details. It does not explicitly say when to prefer list_sorties or list_activities over this tool, but the formation/title-matching scope makes the intended use clear.

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, but the description adds real context beyond them: the 92-day window cap, the default date range, oldest-first ordering, the exact definition of places_left (confirmed participants only, pending requests not deducted), and a prompt-injection warning on untrusted_member_text. It does not mention pagination or a default limit behavior, which is the main remaining behavioral gap.

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 scope and read-only statement, then presents filters as a scannable bullet list and return fields in one closing sentence. Dense but every clause (defaults, caps, places_left semantics, untrusted-text warning) carries information an agent needs.

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 still enumerates the returned fields (id, activity, date, start/end, price_eur, availability, url, untrusted_member_text contents), which is more than adequate for an 8-parameter listing tool. The only incompleteness is the undocumented 'limit' parameter and the absence of pagination guidance.

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 must carry the full burden and largely does: date format and defaults, activity code examples with fuzzy matching note, difficulty as case/accent-insensitive substring with examples and the caveat that difficulty only exists for upcoming outings, the five availability values with definitions, search as title substring, and include_cancelled. Only 'limit' is left undocumented, a small omission against seven well-explained parameters.

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 ('List the club's collective outings'), the scope (starting between start_date and end_date), the ordering (oldest first), and the read-only nature. It is immediately distinguishable from get_sortie (detail view) and list_activities (activity codes), both of which it names.

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 routes the agent: use this for filtered listing, 'Call get_sortie for everything else', and consult list_activities for activity codes. It also states date-window constraints (at most 92 days, years up to next year + 1) that govern when the call will succeed.

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