Fun Friday

Plan a Fun Friday game for later

funfriday_schedule_session

Plan a Fun Friday game for a future date and time, and get back an invite link to put in the team's calendar invite or chat. The invite page shows the game and time in each person's own timezone and lets them add it to their calendar; when it is time, the host opens the room from the same link and the team joins with the code it shows. Nothing is used up until the room is opened. Use this for "set up trivia for Friday at 4" (or, with repeat_weekly, "every Friday at 4") — use funfriday_create_session instead when the team wants to play now. Confirm the game, day, time and timezone with the user before calling it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "game_type": "<game_type>",
      "starts_at": "<starts_at>",
      "timezone": "<timezone>"
    },
    "name": "funfriday_schedule_session"
  }
}

Input Schema

Name	Required	Description
`reminder`	No	Email the organiser a reminder shortly before the start. Needs at least 16 minutes' notice. Default false.
`timezone`	Yes	The organiser's IANA timezone, e.g. "Europe/London" or "America/New_York". Used to write the time on the invite.
`game_type`	Yes	Which game to plan. Call funfriday_list_games first if unsure; this is the internal key, not the display name (Imposter is "faker", Colour Clue is "hues_cues").
`starts_at`	Yes	When the game starts, as an ISO 8601 date-time with a UTC offset, e.g. "2026-11-20T16:00:00+00:00". Work it out in the user's own timezone; it must be in the future and within a year.
`repeat_weekly`	No	Repeat every week at the same local time, for a standing slot like "every Friday at 4". The invite link stays the same and always opens the next game, so it can go in a recurring calendar invite. Cancelling it on the invite page ends the series. Default false.

Output Schema

Name	Required	Description
`status`	Yes	"planned" until the host opens the room, then "ready".
`join_url`	Yes	The room's join link once it is open; null before.
`reminder`	Yes
`timezone`	Yes
`game_name`	Yes
`game_type`	Yes
`starts_at`	Yes
`invite_url`	Yes
`local_time`	Yes	The start time written out in the plan's timezone.
`repeats_weekly`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 12, 2026

addedInput schema / properties / repeat_weekly

Added value: +{
+  "default": false,
+  "description": "Repeat every week at the same local time, for a standing slot like \"every Friday at 4\". The invite link stays the same and always opens the next game, so it can go in a recurring calendar invite. Cancelling it on the invite page ends the series. Default false.",
+  "type": "boolean"
+}

addedOutput schema / properties / repeats_weekly
```
Added value: +{
+  "type": "boolean"
+}
```

changedOutput schema / required

Previous value: -[
-  "game_type",
-  "game_name",
-  "starts_at",
-  "timezone",
-  "local_time",
-  "status",
-  "reminder",
-  "invite_url",
-  "join_url"
-]New value: +[
+  "game_type",
+  "game_name",
+  "starts_at",
+  "timezone",
+  "local_time",
+  "status",
+  "reminder",
+  "repeats_weekly",
+  "invite_url",
+  "join_url"
+]

AddedNov 12, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false, which already tell the agent this creates a non-destructive local object), the description explains the full lifecycle: the link shows local times, the host opens the room from it, nothing is consumed until the room opens, and cancelling a recurring series ends it. The reminder's 16-minute notice requirement is noted in the schema rather than here, but the behavioral model an agent needs before committing a write is complete.

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?

It is front-loaded with purpose and the returned artifact, then usage, then the alternative tool, then a pre-call checklist — a sensible order. It runs long for a scheduled-creation tool, and a few clauses (each person's own timezone, joining with the code) are flavour that an agent doesn't need to act on.

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

Completeness5/5

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 needn't be spelled out, yet the description still tells the agent what the link is for and how it behaves across the session and across weekly repeats. For a 5-parameter scheduling mutation with one enum, nothing an agent needs to call it correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already defines timezone format, ISO 8601 starts_at, game_type enum keys, and repeat_weekly semantics. The description reinforces repeat_weekly's meaning with a concrete phrasing ("every Friday at 4") and adds pre-call validation advice, but adds no new parameter detail beyond what is already structured — the baseline 3 is appropriate.

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?

The first sentence names a specific verb and resource (plan a game for a future date/time) and states the concrete artifact returned (an invite link for calendar or chat). It explicitly contrasts with the sibling funfriday_create_session for 'play now' cases, so an agent can distinguish the two without opening a schema.

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

Usage Guidelines5/5

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

It gives an explicit when-to-use example ("set up trivia for Friday at 4", including the repeat_weekly variant), names the alternative tool and the condition that selects it (team wants to play now), and instructs the agent to confirm game, day, time and timezone with the user before calling.

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?