Fun Friday

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

Annotations already mark this as a non-destructive write; the description goes further by disclosing that a custom pack REPLACES the game's built-in content, that a Pro/Business plan is required, and that the plan caps how many packs a team can keep. These are non-obvious operational constraints beyond what annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action and pack types before the constraints. The plan-cap sentence is dense but earns its place by preventing failed calls; the description is slightly long but almost every clause carries routing or prerequisite 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?

An output schema exists so return values need no explanation, and the description still covers prerequisites (plan tier, lobby selection), alternatives (non-supported games), and validation guidance for each content list. Nothing an agent needs 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 100% so the baseline is 3, and the description earns an extra point by telling the agent to send content 'in the one list that matches pack_type' — genuine cross-field guidance tying the required pack_type to which optional array to populate. It doesn't add format or validation detail beyond the schema, so not 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 (Create) and resource (custom content pack) and enumerates the three pack types with the games they map to. It also names the scope constraint that only these three games accept packs, making it clearly distinguishable from siblings like list_games or create_session.

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

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

Explicitly says when NOT to use it ('for any other game, say so rather than calling this'), which list to populate per pack_type, and that the host picks the pack in the lobby before Start. It also routes the agent to funfriday_get_team when unsure about plan limits.

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

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

With destructiveHint=true and readOnlyHint=false already set, the description adds important behavioral context beyond annotations: it opens a real room, people can join immediately, and it consumes one of the team's weekly games. It does not cover auth or rate limits, but the confirmation warning is a meaningful addition.

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 two tight sentences with the primary purpose and return value front-loaded. The second sentence adds only important side-effect and confirmation context, with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a one-parameter tool with a rich enum schema and an output schema, the description provides everything an agent needs: what it creates, that the room is immediately joinable, that a weekly game is consumed, and that user confirmation is required. Return details are covered by the output schema.

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 game_type enum is fully documented in the schema, including examples and guidance to call funfriday_list_games first. The description adds no additional parameter semantics, so the baseline of 3 is 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 states a specific action and resource: 'Start a new Fun Friday game session,' and immediately names the outcome ('room code and join link'). This distinguishes it from sibling read/list tools like funfriday_get_session and funfriday_list_sessions without needing to inspect schemas.

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 a clear precondition—'confirm with the user before calling it'—and context that the session uses one of the team's games for the week. It does not explicitly name alternatives or when-not-to-use conditions, though the schema points to funfriday_list_games when unsure.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds meaningful scope beyond that: the data is all-time and spans 'across all sessions', i.e. a cross-session aggregate rather than a single-session view — a real behavioral distinction that shapes how results are interpreted.

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 scope ('all-time ... for the user's team') is front-loaded before the usage hint. Nothing redundant with 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?

An output schema exists, so return-format detail is not required, and the description already previews the key fields. With one optional param, no required inputs and full annotation coverage, an agent has everything needed to invoke this 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 'limit' param is fully documented (range 1–100, default 20) in the schema itself. The description says nothing beyond the schema about the param, 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 ('Get the all-time Fun Friday leaderboard for the user's team') and enumerates what is returned (total score, games played, rank). The resource is unique among its siblings (create_pack, create_session, get_session, get_team, list_games, list_sessions), so an agent can distinguish it immediately.

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 usage context with example intents ('who is top of the leaderboard?', 'write up a standings summary'). However, it names no alternatives or when-not conditions, so routing versus e.g. funfriday_get_team or funfriday_list_sessions 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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds genuinely useful behavior beyond them: this is a live 'right now' snapshot and the session has distinct lobby vs. playing states, implying the result changes over time and between calls.

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 payload contents are front-loaded before the example use cases. 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 single-parameter read tool with a full input schema, an output schema, and annotations covering safety, nothing material is missing. The description supplies the liveness framing that the structured fields cannot express.

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 one parameter and schema coverage is 100%, so the schema already documents room_code fully, including its six-character format, case-insensitivity, and excluded characters. The description adds nothing about the parameter, which is the expected baseline when the schema does the work.

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 ('check what is happening in a Fun Friday session') and enumerates the payload: lobby/playing status, joined players, current scores. It is clear, but it does not distinguish itself from the sibling funfriday_get_leaderboard, which the phrase 'who is winning?' could equally point to.

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

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

Gives concrete triggering questions ('has everyone joined yet?', 'who is winning?') and a framing condition ('without opening the browser'), which tells the agent when this is the right call. It stops short of naming an alternative tool or a when-not condition, so it lands at clear-context rather than explicit routing.

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. Most of what the description adds is a restatement of return fields, and the tool has an output schema that already documents those, so genuine behavioral value beyond structured data is limited to the implicit 'this week's games' / pack-retention framing.

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 that opens with the purpose and then layers on usage conditions. It is slightly dense — the field enumeration arguably belongs to the output schema — but no sentence is wasted or redundant within itself.

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 supplies everything an agent needs to decide to call it. The only shortfall is that it spends budget re-describing outputs rather than adding scope or freshness caveats.

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 and additionalProperties is false, so there is nothing for the description to disambiguate. Baseline of 4 applies; no parameter guidance is needed or missing.

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?

It states a specific verb and resource ('Get the user's Fun Friday team') and then enumerates exactly what that returns — name, member count, plan, games remaining this week, custom packs and keep limit. That enumeration is enough to tell it apart from siblings like funfriday_get_session or funfriday_get_leaderboard 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?

Three concrete trigger conditions are given: before hosting (to confirm a game remains), before funfriday_create_pack (to confirm pack capacity), and to answer plan/limit questions. An alternative tool is named with the condition that selects it, leaving nothing 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 establish this as a safe, non-destructive local read (readOnlyHint=true, openWorldHint=false), so the description's extra value is the disclosure that premium games are listed and flagged rather than silently filtered. That is useful behavioral context beyond the annotations, though rate limits or pagination behavior are not addressed.

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 the resource and returned fields front-loaded and the usage guidance immediately after. No filler or redundant restatement of the 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?

For a read-only one-parameter list tool, the description covers purpose, returned fields, and the downstream workflow, while the output schema handles return shape. Nothing needed 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 description coverage is 100% and the single include_premium parameter is fully documented in the schema, so the schema carries the burden. The description's mention of 'whether it needs a paid plan' corroborates but does not extend the schema's default/flagging 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 (List) and resource (team-building games on Fun Friday) and enumerates the returned attributes (name, description, ideal group size, paid-plan flag). It is clearly distinguishable from the mutating siblings such as funfriday_create_session and funfriday_create_pack.

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 names two use cases — answering 'what could we play?' and picking a game_type before calling funfriday_create_session — which routes the agent to the correct follow-up tool. This is a concrete when-to-use with a named downstream alternative.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered externally. The description adds ordering ('most recent first') and the shape of each row, which is modest added context, but nothing about pagination limits or permissions beyond what the schema/annotations give.

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 returned and in what order, the second gives the queries it answers. 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?

An output schema exists, so return values need not be re-explained, and the annotations fully cover the read-only safety profile. The description supplies the team scope, ordering and use cases, leaving nothing an agent needs to decide to call it.

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

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

Schema description coverage is 100% and the single 'limit' parameter is documented there with range and default, so the schema carries the burden. The description's 'most recent first' merely confirms the ordering the schema already implies and adds no new parameter meaning. Baseline 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?

States a specific verb (List) and resource (Fun Friday sessions) and immediately scopes it to 'this team... recently, most recent first', which separates it from the singular funfriday_get_session and from funfriday_get_leaderboard. It also enumerates the returned content (game, when, participant count, winner), so an agent knows exactly what it gets.

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

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

Gives concrete trigger queries ('when did we last do a Fun Friday?') and a use case (summarise the last few weeks), which is clear context for when to reach for it. It stops short of naming alternatives or exclusions, e.g. when to prefer funfriday_get_session or the leaderboard instead.

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