Fun Friday

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so mutation is known; the description adds genuinely new context — that a real, immediately joinable room is created and that it consumes one of the team's games for the week, which implies a quota. The user-confirmation requirement is a behavioral constraint not derivable from the 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?

Two sentences, front-loaded with the action and its payoff (room code and join link), followed by the side effect and the confirmation guardrail. No filler or restated name/title.

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 annotations covering the safety profile and an output schema covering return values, the description supplies the missing operational context: real-world room creation, weekly game consumption, and user confirmation. It does not address whether starting a session conflicts with or supersedes an already-active one, a minor gap for a create 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 coverage is 100% and the game_type property already documents the enum, the display-name mapping (Imposter="faker"), and the pointer to funfriday_list_games. The description adds only the indirect hint that the chosen game draws on the team's weekly allotment, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Start a new Fun Friday game session") and immediately distinguishes itself from the sibling read tools by noting it returns a room code and join link. An agent can tell it apart from funfriday_get_session and funfriday_list_sessions without opening any 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 a clear precondition ("confirm with the user before calling it") and the schema points to funfriday_list_games when the game key is unknown. It stops short of explicit when-not guidance or naming which sibling to use instead when a session already exists.

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 the safe read profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds meaningful behavior beyond them: the data is cumulative and aggregated across all sessions for the team, which is the key distinction from per-session tools.

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: the first front-loads what is retrieved and its scope, the second gives use cases. Nothing is repeated from the title or 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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. Scope, content and usage are all covered; only the pagination/limit nuance is left implicit, which the schema largely handles.

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 (limit) and schema description coverage is 100%, so the schema already documents range and default. The description says 'every player's total score' but does not clarify that the result set is capped by limit, adding no meaning beyond the schema; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource ('Get the all-time Fun Friday leaderboard'), names the scope (user's team, all sessions) and enumerates the returned fields (total score, games played, rank). An agent can distinguish it from the sibling session/game/team tools on the resource alone.

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 provides concrete usage triggers ('who is top of the leaderboard?', 'write up a standings summary'), which is clear positive guidance. It stops short of naming alternatives or stating when not to use it (e.g., a single-session view via funfriday_get_session).

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, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds that it reflects 'right now' state, which is useful for a live session. However, since an output schema exists, restating the returned fields (state, joiners, scores) adds little behavioral value, and no error or freshness guarantees are 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?

Two tight sentences, front-loaded with the core purpose before the example questions. The embedded example questions are mildly verbose but directly aid selection and earn their 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?

With annotations covering safety and an output schema describing return values, the description needn't re-explain results; it complements them with a 'live/right now' framing. It omits failure handling (invalid or expired room code), which is a minor gap for a single-param read 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 coverage is 100% and the single room_code parameter is thoroughly documented (length, case-insensitivity, excluded characters, example). The description adds nothing about the parameter, so the schema does the heavy lifting — baseline 3.

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 ('Check what is happening in a Fun Friday session') and enumerates the returned facets: lobby/play state, participants, and scores. This clearly separates it from siblings like funfriday_list_sessions (enumerate sessions) and funfriday_get_leaderboard (rankings).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides concrete triggering questions ('has everyone joined yet?', 'who is winning?') and a context cue ('without opening the browser'), which tells the agent when to reach for this tool. It stops short of naming alternatives or stating when not to use it (e.g., vs funfriday_list_sessions).

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 openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the returned fields, but with an output schema present that information is largely redundant, and no auth or rate-limit context is offered.

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, with the returned data front-loaded and the usage guidance following. 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 zero-parameter read tool with annotations covering safety and an output schema covering return shape, the description is sufficient to call it correctly. It is slightly over-explanatory in restating return fields the output schema already defines.

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, which is the baseline-4 case; there is no parameter semantics to explain and the description correctly does not invent any.

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 ('Get the user's Fun Friday team') and enumerates exactly what comes back: name, member count, plan, and remaining games this week. That scope is clearly distinct from the sibling tools for sessions, games, and leaderboards.

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 two concrete triggering contexts: check the team has a game left before hosting, or answer plan/limit questions. No explicit 'when not to use' or named alternative is given, so it falls just short of the top band.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context: premium games are still listed and merely flagged rather than hidden, which explains the include_premium default. It stops short of describing result size, ordering, or whether the catalog is static.

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: capability and return shape first, routing guidance second. Every clause carries information and nothing is repeated from the schema 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?

An output schema exists, so return values need no prose explanation. With usage, routing, and the premium-flagging behavior all covered for a zero-required-parameter read tool, an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single parameter's schema text already explains the default and the flagging rationale in detail. The description's mention of 'whether it needs a paid plan' reinforces but does not extend that meaning, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List the team-building games available to play on Fun Friday') and enumerates the returned attributes (name, description, ideal group size, paid-plan flag). It is unmistakably distinct from the session/leaderboard/team 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 an explicit trigger ('what could we play?') and an explicit downstream use ('pick a game_type before calling funfriday_create_session'), naming the sibling tool by name. Nothing about when to reach for it is left to inference.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so the safety profile is clear. Description adds sort order (most recent first) and team scoping, which are useful, but does not add pagination/limit behavior or return shape details beyond the field list. With annotations covering the safety profile, this is adequate but not rich.

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, front-loaded with the action and resource, followed by a crisp enumeration of returned fields and concrete usage triggers. Zero 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 list tool with one optional param, full schema coverage, and an output schema already present. The description covers scope, sort order, returned fields, and usage triggers – everything needed to call it correctly. Output schema handles return details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% – the 'limit' parameter is fully documented in the schema (range 1–50, default 10, newest first). The description adds nothing about parameters beyond what the schema already provides. Baseline 3 when schema does the heavy lifting.

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 (List) + resource (Fun Friday sessions) + scope (this team, recently) + sort order. Output fields are enumerated (game, when, participants, winner), distinguishing it from siblings like funfriday_get_session (single) and funfriday_get_leaderboard (aggregate).

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?

Explicit when-to-use cases given as sample questions: 'when did we last do a Fun Friday?' or summarising recent weeks. This tells the agent not just what but when, and implicitly contrasts with single-session and leaderboard siblings.

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