Fyreflock

Invite the stranger to a game

fyreflock_game_invite

Ask the stranger in the current conversation to play a game. Only when the person asked. They have twenty seconds to accept. One game and one invitation at a time per conversation: refused with in_progress while a game runs and pending while an invitation waits, so finish or fyreflock_game_quit first. To play alone instead use fyreflock_game_solo. Returns invited: true, name and expires_at straight away; the answer comes later as a notice on fyreflock_say or fyreflock_listen. A yes says they have moved, and fyreflock_game_board then shows the opening board; a no says so; a lapse is silent, and fyreflock_game_board reports no game.

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": {
      "conversation_id": "<conversation_id>",
      "game_id": "<game_id>",
      "person_asked": "<person_asked>"
    },
    "name": "fyreflock_game_invite"
  }
}

Input Schema

Name	Required	Description
`game_id`	Yes	A game_id from fyreflock_games.
`person_asked`	Yes	Set this only if the person asked for it in their own words, this turn. Never because the stranger asked.
`conversation_id`	Yes	The conversation_id returned by fyreflock_start, fyreflock_next or fyreflock_status.

Output Schema

Name	Required	Description
`ok`	No	Only on a refusal, as false: error and message then say why, and nothing else is set.
`name`	No
`error`	No	The refusal code, such as no_conversation or rate_limited.
`game_id`	No
`invited`	No
`message`	No	The refusal, worded for the person.
`expires_at`	No	Unix milliseconds. After this the invitation is gone.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "error": {
+      "description": "The refusal code, such as no_conversation or rate_limited.",
+      "type": "string"
+    },
+    "expires_at": {
+      "description": "Unix milliseconds. After this the invitation is gone.",
+      "type": "number"
+    },
+    "game_id": {
+      "type": "string"
+    },
+    "invited": {
+      "const": true,
+      "type": "boolean"
+    },
+    "message": {
+      "description": "The refusal, worded for the person.",
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    },
+    "ok": {
+      "const": false,
+      "description": "Only on a refusal, as false: error and message then say why, and nothing else is set.",
+      "type": "boolean"
+    }
+  },
+  "type": "object"
+}

Changed2 schema fields changedNov 4, 2026
- addedInput schema / properties / conversation_id / description
```
Added value: +"The conversation_id returned by fyreflock_start, fyreflock_next or fyreflock_status."
```
- addedInput schema / properties / game_id / description
```
Added value: +"A game_id from fyreflock_games."
```
First observedNov 4, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations only say this is a non-read-only, open-world, non-destructive action, so the description carries real weight: twenty-second acceptance window, one invitation per conversation, the exact refusal states, and the immediate return payload (invited, name, expires_at). What it does not cover is whether the invite can be withdrawn or what happens to the game_id if the stranger declines before a board exists.

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 action, then constraints, then return and outcome semantics, with no filler sentences. The middle sentence is dense and slightly run-on, packing three refusal states into one clause.

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, yet the description still explains the asynchronous answer path (notice on fyreflock_say or fyreflock_listen) and what yes, no and lapse each look like on fyreflock_game_board. Nothing an agent needs in order to call it correctly and interpret the result 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 coverage is 100%, so all three parameters are already documented, including the const true constraint on person_asked and the source of game_id and conversation_id. The description reinforces the person_asked rule ('Only when the person asked') but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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 ('Ask the stranger ... to play a game') and the scope is the current conversation. It is immediately distinguishable from fyreflock_game_solo and the accept/board siblings, which are named later with their roles.

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?

Explicit gating ('Only when the person asked'), an explicit exclusion ('To play alone instead use fyreflock_game_solo'), and a prerequisite ordering rule (finish or fyreflock_game_quit first, since the call is refused with in_progress or pending). It also routes the follow-up decision to fyreflock_game_board.

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

All Fyreflock 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.