Fun Friday

Recap a Fun Friday

funfriday_get_recap

Read-only

Get a recap of a finished Fun Friday room: every game played and who won it, the overall table across those games, the top of the team's all-time leaderboard, the user's next planned game if there is one, and a link to the full results page. The text is ready to paste into Slack, Teams or email; the structured result is there for writing your own version. Leave out room_code for the team's most recent finished room. Use this for "write up today's Fun Friday for the team channel". It only reads — post it with your own messaging tools.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "funfriday_get_recap"
  }
}

Input Schema

Name	Required	Description	Default
`room_code`	No	The six-character room code for the session, e.g. "K7PQ2M". Case-insensitive. Room codes never contain the letters I or O, or the digits 0 or 1. Optional: leave it out for the most recent finished room.

Output Schema

Name	Required	Description
`games`	Yes
`wrap_url`	Yes
`next_game`	Yes	The caller's next planned game, if they have one.
`played_on`	Yes	The date the room was opened, YYYY-MM-DD.
`room_code`	Yes
`standings`	Yes	The room's overall table across every game played in it.
`all_time_top`	Yes	The top three on the team's all-time leaderboard; empty for a room with no team.
`player_count`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 12, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already establish readOnly=true, destructive=false, openWorld=false, so the safety profile is covered. The description adds genuinely new behavior: the output comes in two forms (Slack/Teams/email-ready text plus a structured result) and it performs no posting. It does not address what happens when no finished room exists or how far back the recap reaches in games, which are the remaining behavioral unknowns.

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

Conciseness4/5

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

Front-loaded with the payoff (a recap of a finished room) followed by the content list, the default behavior, and the usage cue, in that order. The content list is long but each item earns its place by telling the agent what will be returned. Slightly dense, with the Slack/Teams sentence and the "only reads" sentence carrying overlapping intent.

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

Completeness4/5

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

An output schema exists, so the description is not obligated to explain return values, and it correctly focuses on content inventory, defaults, and the no-side-effect contract. For a read-only, single-optional-parameter tool this is close to complete. The only missing piece is behavior when the team has no finished room yet.

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

Parameters5/5

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

Schema coverage is 100% and the single parameter is fully documented in-schema, including the six-character format and the I/O/0/1 exclusion rule. The description's default-value note ("Leave out room_code for the team's most recent finished room") repeats the schema but reinforces the optionality at the point of use. Nothing is left ambiguous about the parameter.

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

Purpose5/5

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

States a specific verb and resource ("Get a recap of a finished Fun Friday room") and then enumerates exactly what the recap contains — games played and winners, cross-game table, top of all-time leaderboard, next planned game, results link. That enumeration distinguishes it from siblings like funfriday_get_session and funfriday_get_leaderboard without naming them, since an agent can see this tool is a composite summary rather than a raw resource fetch.

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

Usage Guidelines4/5

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

Gives a concrete triggering phrase ("write up today's Fun Friday for the team channel") plus the key calling rule that omitting room_code targets the most recent finished room. It also notes the read-only hand-off ("post it with your own messaging tools"), which prevents an agent from hunting for a send/post tool here. It stops short of explicit when-not guidance or naming a sibling alternative for raw session data, so it is clear context but not full routing.

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

All Fun Friday tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?