Fyreflock

Skip to someone else

fyreflock_next

Destructive

End the current conversation and look for a different stranger. Only when the person clearly asked to skip. The other person is told it ended, and the same person will not be handed back straight away. To stop without looking for anybody new, use fyreflock_leave instead. Returns the same shape as fyreflock_start: matched with a new conversation_id and peer, or searching when nobody new is waiting yet, in which case tell them and stop.

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>",
      "person_asked": "<person_asked>"
    },
    "name": "fyreflock_next"
  }
}

Input Schema

Name	Required	Description	Default
`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.
`peer`	No
`error`	No	The refusal code, such as no_conversation or rate_limited.
`queue`	No
`status`	No
`message`	No	The refusal, worded for the person.
`notices`	No
`conversation_id`	No	The new conversation, only when matched.

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": {
+    "conversation_id": {
+      "description": "The new conversation, only when matched.",
+      "type": "string"
+    },
+    "error": {
+      "description": "The refusal code, such as no_conversation or rate_limited.",
+      "type": "string"
+    },
+    "message": {
+      "description": "The refusal, worded for the person.",
+      "type": "string"
+    },
+    "notices": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "ok": {
+      "const": false,
+      "description": "Only on a refusal, as false: error and message then say why, and nothing else is set.",
+      "type": "boolean"
+    },
+    "peer": {
+      "type": "string"
+    },
+    "queue": {},
+    "status": {
+      "enum": [
+        "matched",
+        "searching"
+      ],
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changed1 schema field changedNov 4, 2026

addedInput schema / properties / conversation_id / description

Added value: +"The conversation_id returned by fyreflock_start, fyreflock_next or fyreflock_status."

First observedNov 4, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the destructiveHint/openWorldHint annotations: it discloses side effects on the third party ('The other person is told it ended'), a matching fairness rule ('the same person will not be handed back straight away'), and a 'searching' outcome state with instructions on what to tell the user. This is exactly the extra behavioral context annotations can't convey.

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-loads the action, then the guard condition, then the side effects and alternative. Dense and mostly waste-free, though the final sentence runs long by chaining the return shape and the follow-up instruction together.

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?

Covers the action, the precondition, third-party side effects, the anti-rematch rule, the alternative tool, and the possible outcome states, even though an output schema exists and returns technically didn't need documenting. Nothing an agent needs to call or narrate this 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 coverage is 100%, so the schema already documents both parameters including the subtle 'person_asked must be true and from the user's own words' constraint. The description reinforces the ask-before-skip condition but adds no format or usage detail the schema lacks, 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?

States a specific verb and resource ('End the current conversation and look for a different stranger'), which is clearly distinct from fyreflock_leave (stop without re-matching) and fyreflock_start (begin). An agent can route correctly 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.

Usage Guidelines5/5

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

Gives an explicit precondition ('Only when the person clearly asked to skip') and names the alternative for the other case ('To stop without looking for anybody new, use fyreflock_leave instead'). When-to-use, when-not-to-use, and the alternative are all present.

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.