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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered. The description adds genuinely useful, non-redundant context — validation occurs locally and the token is never returned — which addresses the obvious security concern an agent would have.

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 purpose and followed immediately by the security guarantee. No filler, no repetition of the title or annotations.

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 does the work by naming the two returned facts (availability, owner identity) and the one thing withheld (the token). It stops short of describing the failure/expiry shape or what the caller should do next, which is a minor gap for a simple status probe.

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 the baseline is 4; there is nothing for the description to disambiguate or annotate.

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 ('Show') and the exact resource/condition ('whether a local B2match token is available and, when valid, who it belongs to'). This is unmistakably distinct from every sibling, which are all domain-content tools rather than auth checks.

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 rather than stated: an agent can infer this is a pre-flight auth check, but the description never says when to call it (e.g., before other tools) or what to do on failure. No alternatives are named because none exist, but the when-to-use framing is absent.

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, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description reinforces this with 'Does not book anything,' a small additive clarification, but discloses nothing about cost, rate limits, or the semantics of the long-term-networking flag.

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 action and followed by the single most important non-behavioral caveat. Nothing is wasted and nothing is buried.

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 five parameters, no output schema, and no annotations gap around safety, the definition is only partially complete. It should clarify the format/units expected for 'day' and 'duration' and what the returned slots look like, none of which is recoverable from structured 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?

Schema coverage is only 20% (only 'event' is documented), so the description must carry the rest and does not. It vaguely gestures at participant_ids via 'selected participants' but says nothing about day, duration, or is_long_term_networking, leaving three parameters undocumented in both places.

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 object ('Read common free meeting slots') plus the scope ('for the viewer and selected participants'), which is enough to distinguish it from single-party siblings like my_availability. It never names an alternative sibling, so differentiation is inferred rather than explicit.

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?

'Does not book anything' implicitly tells the agent this is a pre-booking discovery step rather than a scheduling action, which is useful. However, no sibling is named as an alternative (e.g., my_availability vs. meeting_recommendations) and no condition is given for when this should be preferred.

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, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful non-schema behavior — that the menu path is resolved automatically — but says nothing about result shape, size, or pagination for a list-style read.

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, no filler, and the core purpose is front-loaded ahead of the path-override caveat. Every clause 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?

For a two-parameter, annotation-covered read tool with no output schema, the description supplies the purpose, the returned content categories, and the override behavior. It is slightly thin on return structure and the exact scope of an 'agenda', but nothing required to invoke 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?

Schema coverage is only 50%: 'event' is documented in the schema, but 'path' has no description there. The description compensates for exactly that gap by explaining 'path' is an override for an automatically resolved value, which an agent could not infer from a bare string parameter.

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 concrete verb plus the two resources it returns ('agenda sessions and networking blocks'), which is specific enough for an agent to pick it over get_session (a single session) or get_event (event metadata). It does not name any sibling explicitly, so it stops 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?

Usage is only implied: an agent infers this is the way to pull an event's agenda. There is no statement of when to use it versus get_session, list_session_attendees, or my_schedule, and no prerequisites or exclusions are given. The only guidance offered concerns the path override.

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?

The description discloses genuinely valuable behavior beyond the annotations: the server-side read-marking side effect, the feature-flag gating, the acknowledge_marks_read requirement, and not-found behavior for unknown ids. However, this directly conflicts with the readOnlyHint=true annotation, so the agent receives contradictory safety signals about whether the call mutates state.

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 action is front-loaded and every sentence carries information (side effect, gating, alternative, error behavior). It is dense — four ideas packed into one paragraph — but no sentence is 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?

For a read tool with a hidden side effect, the description covers the essential call-time concerns: gating, required acknowledgement, side effect, alternative tool, and error behavior. No output schema exists, so return values need not be described. Only the annotation conflict keeps it from being fully complete.

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 only 50% schema description coverage, the description compensates by explaining acknowledge_marks_read's gating role ('Disabled unless ... acknowledge_marks_read is true') and conversation_id's failure mode ('Unknown ids return a not-found error'). This adds meaning beyond the bare schema for both 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+resource ('Fetch conversation messages') and immediately distinguishes itself from the sibling by contrasting full messages against list_conversations' last-message previews. An agent can tell the two apart without opening either 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 routes the agent: 'Use list_conversations for last-message previews,' and states the enabling condition (B2MATCH_ALLOW_SIDE_EFFECT_READS=1 and acknowledge_marks_read=true). It implies rather than spells out 'use this when you need full message bodies,' so it falls just short of a full when/when-not treatment.

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=true, so the safety profile is fully covered by structured data. The description adds one genuinely useful behavioral fact — that only public event data is returned, not the caller's private participation — but nothing about caching, auth requirements, or failure modes for an invalid event identifier.

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, front-loaded with the verb and resource, listing returned content without filler. Nothing is wasted or buried.

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?

Because no output schema exists, the description must carry return-value information, and it does by enumerating the fetched fields. It stops short of stating prerequisites (e.g., that the event must exist or be accessible) or how it relates to the many sibling event-scoped 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?

With a single parameter and 100% schema description coverage, the schema already explains that 'event' accepts a URL, slug/euid, or numeric id. The description adds nothing about accepted identifier forms, 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 (Fetch) and resource (public event metadata) and enumerates the content returned: dates, registration window, login methods, navigation. The word 'public' implicitly separates it from user-scoped siblings like list_my_events or my_participation, though it never names 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?

There is no when-to-use or when-not-to-use guidance and no alternative tool is named. An agent must infer from the name alone that this is the entry point for resolving an event before calling the more specific sibling tools.

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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is lower, and the description still adds real behavior: the marketplace menu path is resolved automatically and can be overridden via path. It does not mention failure modes for invalid ids or the shape of the returned opportunity, keeping it at a 4.

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 tightly packed sentences, front-loaded with the action and followed by the id-sourcing caveat and the path-override behavior. The parenthetical carries non-obvious routing information, so nothing reads as 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?

For a read-only, idempotent single-resource fetch with no output schema, the description covers what is needed to call it correctly: which id to supply, where to get it, and how path resolution behaves. Since no output schema exists, a brief note on what the returned opportunity contains would make it complete.

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 only 33% (only event is documented in the schema), so the description must compensate. It does explain opportunity_id's accepted forms and sourcing, and clarifies path as an override for auto-resolution; event remains covered by the schema. The one gap is that opportunity_id's type/format nuances rely mostly on the surrounding prose.

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 (Fetch) and resource (a marketplace opportunity) and disambiguates itself from siblings by specifying which ids to use: those from list_opportunities rather than the different opportunity ids surfaced by my_participation. An agent can tell this apart from list_opportunities without opening either 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?

Gives clear context for correct invocation, naming list_opportunities as the id source and warning that marketplace ids differ from my_participation ids. It does not state explicit when-not-to-use conditions or name a competing retrieval tool, so it falls short of a 5.

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 openWorld, so the safety profile is covered. The description adds a genuine behavioral trait absent from structured fields: automatic menu-path resolution with an explicit override. It stops short of auth requirements, failure modes, or what happens when resolution fails.

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, front-loaded with the action and followed by the path behavior. Every clause carries information, though the 'organisation/participation page' phrase trades precision for brevity.

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 would ideally hint at what is returned, yet it does not. With 33% schema coverage and no explanation of why a participation_id is required to fetch an organisation, meaningful gaps remain for a three-parameter tool, though the annotations carry the safety dimension.

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 only 33%: only 'event' is described in the schema, while 'participation_id' is undocumented everywhere. The description explains that 'path' is an override for auto-resolution, adding intent beyond the bare string type, but gives no syntax or format for the path and says nothing about participation_id.

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 clear verb ('Fetch') plus resource ('organisation/participation page'), and the name/title line up with the sibling list_organisations by being the singular fetch. However, the pairing of 'organisation/participation page' is ambiguous — an agent can't tell whether the primary resource is an organisation or a participation, nor how this differs from get_participant.

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 guidance, no prerequisites, and no mention of alternatives such as list_organisations or get_participant. The only conditional statement is about the path override, which is a parameter mechanic rather than usage 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 readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious context: that this fetch suppresses B2match's profile-view tracking mutation, which an agent could not infer from structured fields. It stops short of auth or error behavior, so not a 5.

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 zero filler. The differentiating detail (no tracking mutation) is placed immediately after the core action.

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 two-parameter read tool with no output schema, the description covers the action, the return concept, and one behavioral nuance. It leaves the participant_id format and any error/not-found behavior unaddressed, which is a modest but real 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 coverage is only 50%: 'event' is documented but 'participant_id' has no description in either the schema or the description. With a bare, undocumented identifier parameter, the description should have compensated with format or accepted-value guidance and does not.

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 ('Fetch') and resource ('participant profile'), which is clearly distinguishable from sibling list tools like list_participants. The added clause about skipping the tracking mutation further narrows what this tool uniquely does, though it never names a sibling 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?

The description gives no when-to-use guidance, no prerequisites, and does not name an alternative such as get_event or list_participants. The only hint is the implied preference for an untracked fetch, which is a behavioral note rather than usage direction.

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 the safety profile is covered. The description usefully adds the path/session_id precedence rule, but says nothing about the paging behavior implied by attendees_first/attendees_after. With annotations carrying the safety burden, a 3 is appropriate.

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 no waste; the parameter-precedence rule is front-loaded after the purpose statement. 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 5-parameter, read-only tool with no output schema and low schema coverage, the description covers the critical path/session_id decision but omits the attendee-pagination parameters and any note on what is returned. Adequate but with clear gaps.

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 only 20% (just 'event'), so the description must compensate. It clarifies path and session_id as alternatives, covering two of the undocumented parameters, but leaves attendees_after and attendees_first unexplained.

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+resource ('Fetch a session route') that an agent can distinguish from siblings like get_event and list_session_attendees. 'Route' is slightly jargon-y, but the intent (retrieve one session) 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?

Gives invocation guidance on which parameter to supply ('Provide session_id, or path ... Path alone is enough'), which is genuinely useful. However, it offers no when-to-use context relative to alternatives such as get_event or list_session_attendees, so selection guidance is only 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?

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower, but the description adds a genuinely useful non-obvious trait: that listing does not mark conversations as read. That is a real behavioral disclosure beyond the annotation set.

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, front-loaded with the core action and followed by the key side-effect note. No wasted words.

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?

A simple read-only list tool with full annotation coverage, complete parameter schema, and no output schema to explain. The description is largely complete; it could have named the sibling alternative, but nothing essential to calling the tool 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?

Schema description coverage is 100%, so the schema fully documents the cursor, event, and page-size parameters. The description adds nothing about parameter usage, which is acceptable given the baseline rule when schema coverage is high.

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 resource (conversations), plus the added scope of 'last-message previews' and that it's limited to authenticated conversations. It clearly contrasts with the sibling get_conversation by being a list rather than a single fetch, though it does not name that sibling 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?

There is no explicit when-to-use guidance or routing to alternatives like get_conversation. The only usage-adjacent sentence ('does not mark conversations as read') is a behavioral trait rather than a condition for selecting this tool.

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, openWorld and non-destructive, so the safety profile is covered. The description's one added behavioral fact is that results are scoped to the authenticated viewer, which is genuinely useful context. It says nothing about ordering, pagination, or result size for an openWorld listing.

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 or redundancy. Every word carries information and the scoping qualifier comes immediately after the verb+resource.

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 read tool with annotations covering safety, the definition is close to sufficient. With no output schema, though, the agent has no idea what an event object looks like or whether the list is paginated, which is a real gap for an openWorld listing endpoint.

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. Baseline 4 applies; no parameter-related omissions are possible.

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 ('List events') and scopes it to the authenticated viewer account, which separates it from the global/other-user listings. It does not, however, differentiate itself from the sibling get_event or clarify what a B2match 'event' contains, so an agent must infer the list-vs-single distinction.

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 guidance, no prerequisites, and no mention of any alternative such as get_event for fetching a single event. The agent is left to infer that this is the entry-point listing tool purely from the name.

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 that fetching resets B2match's unseen counter to 0 even though this client never sends ReadNotification, that the unread counter is unaffected, and that the full list requires a gated env flag. That is exactly the non-obvious side-effect information an agent needs before calling a nominally read-only 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?

Three tight sentences, front-loaded with the default behavior and followed by the side-effect and gating details in order of importance. No filler, though the phrasing is terse enough that a reader may need to re-read the env-var sentence.

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?

There is no output schema, so the description carries the burden of describing return values, and it only characterizes them as counters versus a full list without describing notification fields or the shape of either mode. The side-effect disclosure is thorough, but the return-format gap leaves the definition minimally viable for a list 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?

Schema description coverage is 100%, so after, event, first, and acknowledge_marks_seen are already documented in the schema (including acknowledge_marks_seen's env-var coupling). The description restates acknowledge_marks_seen's effect and adds that unseen resets, but adds nothing about after/first semantics, so the baseline of 3 is correct.

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 the tool returns notification counters (unread/unseen) by default and can return a full list under a flag, which is a concrete resource and behavior. It does not name a sibling tool, but no sibling in the list is a close competitor (the rest are events, participants, meetings, conversations). The 'list' aspect is slightly underemphasized because the opening sentence leads with counters rather than the notification collection.

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 establishes clear context for the two modes: default behavior (counters) versus the full list, plus the explicit prerequisite B2MATCH_ALLOW_SIDE_EFFECT_READS=1 combined with acknowledge_marks_seen=true. It stops short of the 5-level bar because it names no when-not condition or alternative tools.

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 the safety profile is covered. The description adds a genuine behavioral detail the annotations do not: that the menu path is auto-resolved unless overridden. It says nothing about result volume, pagination behavior beyond the cursor in the schema, 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?

Two short sentences, front-loaded with the purpose before the path caveat. Very tight, though the override sentence is slightly cryptic without knowing what a menu path is.

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 could say more about what an opportunity record contains and how results are scoped/paginated. Since pagination parameters (after, first) are documented in the schema, the main residual gap is result scope relative to sibling 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 75%, with `path` being the one undocumented parameter; the description compensates directly by explaining that path overrides automatic menu-path resolution. It still omits the expected format/syntax of path and doesn't restate scoping for `event`.

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 resource (marketplace opportunities), which contrasts cleanly with the singular sibling get_opportunity. It is clear what the tool returns at a category level, though it never says whether it lists for the current user, the event, or globally.

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 second sentence gives conditional guidance for the path parameter ('pass path to override'), which is useful. However, there is no guidance on when to use list_opportunities versus get_opportunity, or whether the event scope is required context.

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, open-world and non-destructive behavior, so the safety profile is covered. The description usefully adds the automatic menu-path resolution behavior, but says nothing about result volume, rate limits, or failure modes when a path is passed incorrectly.

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, with the path-resolution note following. Nothing is wasteful, though the phrasing is terse enough that it could have afforded one more clarifying clause without bloat.

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 paginated list tool with strong readOnly annotations and no output schema, this covers the essentials but omits what a page of results contains and how the after cursor interacts with first. Adequate but with clear gaps given no output schema exists to carry return-shape information.

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 75%; the description fills the notable gap by explaining that path is auto-resolved and only needed to override, which is exactly the param left undocumented in the schema. The other parameters (event, after, first) are already described in the schema, so no further compensation is required.

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 ('List event organisation pages'), which clearly separates it from the singular get_organisation sibling. It stops short of explicitly naming that sibling or defining what a 'page' contains, so it is clear but not maximally differentiating.

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 clause 'Resolves the menu path automatically; pass path to override' gives implicit guidance on when to supply path. There is no stated when-to-use vs get_organisation or list_participants, and no prerequisites, so usage remains inferred.

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/openWorld, so the safety profile is covered. The description adds genuinely useful behavior beyond that: only public participants are returned, and the default response is a compact summary unless detail=true. It says nothing about pagination limits or rate behavior, which the schema only partially covers.

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, zero waste, and the primary purpose is front-loaded before the alternatives. Every clause 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 list tool with no output schema, the description covers scope, default vs. detailed output, and the sibling alternative; pagination is handled by the schema's after/first descriptions. Only the undocumented query parameter and any rate/limit behavior are 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?

Schema coverage is 60%, and the description compensates for the most consequential gap by explaining what detail=true actually changes (compact summary vs. fuller record). The query parameter remains undocumented in both schema and description, which keeps this short of a 5.

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 resource (participants), plus a scoping qualifier (public) and output shape (compact summary). It explicitly differentiates itself from the sibling get_participant, so an agent can choose without opening either 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?

Names two clear alternatives with their selecting conditions: set detail=true for the fuller record, use get_participant for a single profile. That is strong routing guidance, but it offers no explicit when-not-to-use case (e.g., versus list_session_attendees for a session-scoped roster).

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, open-world behavior, so the safety profile is covered. The description adds useful return-shape context (only the attendees connection, not the full route), but says nothing about pagination behavior despite exposing after/first.

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 with the purpose and result scope front-loaded; nothing is padded. The final sentence is terse to the point of underspecification, but the structure itself is efficient.

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 five parameters at 20% coverage, no output schema, and no annotations gap to hide behind, the description should explain the session-identifier alternatives and pagination. It does neither, leaving an agent to guess how after/first behave.

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 only 20% (just 'event'), so the description must compensate and largely does not. It clarifies that session_id or path identify the session, but leaves the relationship between them ambiguous and never explains after/first pagination semantics.

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 attendees for a session") and scopes the result precisely: "Returns only the attendees connection, not the full session route." That implicitly separates it from the get_session sibling, though it never names the sibling outright.

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?

"Provide session_id or path" is an input hint, not usage guidance. The description never says when to choose this over get_session, get_participant, or list_participants, nor any prerequisites such as needing an event context.

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, destructiveHint=false and openWorldHint, so the safety profile is covered structurally. The description adds one genuinely useful behavioral fact — that the menu path is auto-resolved and only needs to be passed to override it — but says nothing about return shape, pagination behavior, or auth requirements.

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 the core purpose front-loaded and no filler. The second sentence is somewhat cryptic ('menu path' is never defined), which slightly undercuts an otherwise tight structure.

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?

There is no output schema, so the description carries the burden of conveying what a speaker record looks like, and it does not. For a listing tool with four parameters, it is minimally viable but leaves the return content and result size entirely to inference.

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 75%, so the schema already documents after, event and first. The description only touches the path parameter, but it does add real meaning there (normally auto-resolved, pass only to override). The 'menu path' concept itself is unexplained, so the added value is limited.

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 event speakers'), which is unambiguous on its own. However, it draws no boundary against sibling list tools such as list_participants or list_session_attendees, so an agent cannot tell from the description alone which list to reach for.

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 context, no prerequisites, and no mention of alternatives like list_participants. The only guidance is the internal 'pass path to override' note, which addresses parameter mechanics rather than tool selection.

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?

The annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so safety and idempotency are covered. The description adds that results are authenticated and include recommended plus newest participants, which is useful context, but it does not explain ranking, result shape, or pagination.

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 concise sentence with no wasted words, and the core action is front-loaded. It could be slightly more structured by separating recommendation logic from authentication context, but it is efficient overall.

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 complete schema coverage and rich annotations, the description is adequate but thin. Since there is no output schema, it should ideally explain what kind of participant data is returned or how "recommended" is determined; instead it leaves those details implicit.

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 is only one parameter and schema description coverage is 100%, so the schema fully documents the event identifier. The description adds no additional semantics about accepted formats or filtering behavior, making the baseline 3 appropriate.

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 the specific verb "Fetch" and identifies the resource as "recommended and newest participants to meet." It is distinct from list_participants because it emphasizes recommendations rather than a general listing, though the phrase "authenticated recommended and newest" is slightly awkward and does not explicitly name the sibling 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?

The description implies a discovery use case, finding participants to meet, but does not explicitly state when to use this tool instead of list_participants, my_meetings, or find_meeting_slots. No exclusions or prerequisites are given beyond "authenticated."

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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so that burden is lifted. The description adds real behavioral value beyond them: it discloses the default return shape (merged free ranges per day) and the alternate verbose mode (full timeslot grid), plus 'authenticated' signals an auth requirement.

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 tightly written sentences with zero filler, and the default behavior is front-loaded before the opt-in flag. Every clause carries actionable 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?

With no output schema, the description usefully characterizes both return modes, which is the main thing an agent needs. It is slightly incomplete on temporal scope (what window of availability is returned, and timezone handling), but covers the branching decision fully.

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 only 50%: 'event' is documented in the schema but 'detail' has no schema description. The description compensates by explaining what detail=true actually returns ('the full timeslot grid') versus the default, which is more than the bare boolean default=false provides.

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 ('Fetch') and resource ('authenticated availability'), and the 'merged free ranges per day' phrasing clarifies it is the caller's own availability rather than generic event data. It does not name any sibling (e.g. my_schedule, find_meeting_slots) to disambiguate, so it is clear but undifferentiated.

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 gives explicit guidance for choosing between the two output modes (default merged ranges vs detail=true grid), which is genuine usage instruction. However it offers no when-to-use guidance relative to sibling tools like my_schedule or find_meeting_slots, so tool selection remains inferred.

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 cover safety (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description still adds real context beyond them: unfiltered responses include a 'compact availability summary (merged free ranges per day)' unless detail=true, and status filters to one bucket. What detail=true actually adds is only implied, not stated.

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, zero filler, and the core purpose is front-loaded before the conditional behavior. Each clause carries information the agent cannot get from the structured fields.

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 a three-parameter tool, the description carries extra burden. It explains the availability-summary behavior and bucket filtering, but never describes the meeting record shape or exactly what detail=true returns, leaving the return contract partially inferred.

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 only 33%, with detail and status documented nowhere in the schema. The description compensates by explaining that status selects a single status bucket and that detail toggles the availability summary in unfiltered responses. That is meaningful added meaning, though the exact effect of detail=true on the returned meeting payload remains unclear.

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 ('Fetch') and resource ('authenticated meetings') and clarifies the scope is the authenticated user's own meetings. However, it does not differentiate from nearby siblings like my_schedule or my_availability, and the mention of an 'availability summary' overlaps conceptually with my_availability, which could cause an agent to hesitate between 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 description describes what happens when status is absent ('optionally returning one status bucket') but gives no when-to-use guidance or exclusions relative to siblings like my_schedule, my_availability, or find_meeting_slots. The agent must infer the decision boundary on its own.

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, openWorld, and non-destructive, so the safety profile is covered. The description adds that this aggregates multiple sub-resources (status, permissions, organisation pages, opportunities) for a single event, which is useful context, but says nothing about auth failure modes or data freshness.

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 wasted words and the scope ('for one event') placed at the end to bound the operation. The crammed list of returned facets reads slightly like an enumeration rather than prose, but nothing is superfluous.

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, enumerating the returned facets (status, activation, permissions, organisation pages, opportunities) is the key completeness contribution and it is present. For a read-only tool whose annotations already convey safety, this is close to sufficient, though auth prerequisites remain unstated.

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% and the single 'event' parameter is fully documented in the schema (URL, slug/euid, numeric id). The description only echoes the one-event scoping already conveyed by the required parameter, adding no extra syntax or format detail.

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 (Fetch) and a well-defined resource set (authenticated participant status, activation, permissions, organisation pages, opportunities) scoped to one event. This distinguishes it from broader siblings like get_event and list_participants, but it does not explicitly contrast itself with nearby 'my_*' tools such as list_my_events or my_schedule.

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 the 'my_/authenticated participant' framing and the 'for one event' scope, but the description never states when to reach for this tool instead of get_participant, list_my_events, or my_schedule. 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?

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely new behavior beyond the annotations: the PDF agenda URL is conditionally omitted unless include_pdf_link is true, which is a non-obvious output-shaping rule.

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, no filler. The core operation is front-loaded and the conditional parameter behavior follows immediately after.

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 carries the return-value burden; it states what is fetched and how the optional PDF link affects the result. Minor gap: no mention of schedule contents or empty-schedule behavior, but nothing that would cause a mis-call.

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 50%, with the undocumented parameter being include_pdf_link. The description directly compensates by explaining its effect on the returned payload, so the gap is closed rather than left to inference.

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 ('Fetch the authenticated viewer's event schedule'), which is clearly a personal schedule rather than an event-wide artifact. It does not explicitly distinguish itself from close siblings like get_agenda or list_my_events, so the agent must infer the boundary from the 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?

Usage is implied by the qualifier 'authenticated viewer's', which signals this is the self-scoped counterpart to event-level tools such as get_agenda. There is no explicit when-to-use statement and no named alternative or exclusion condition.

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