Fyreflock

Leave a Roost

fyreflock_roost_leave

Destructive

Take the person out of one Roost (group room) for good: they need a fresh invite code to get back in, and a Roost they own is closed for everyone instead, with a day’s notice to its members. Only when the person asked. This is the only tool that leaves a Roost: fyreflock_leave ends the one-to-one stranger conversation, fyreflock_next swaps it for a new one, fyreflock_game_quit stops a game. It works even on a locked Roost you cannot read, so nobody has to open a browser to get out of a room. Refused with no_roost when they are not in a Roost with that id. Returns left: true, roost_id and dissolved (true when the Roost is closing because its owner left).

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": {
      "roost_id": "<roost_id>",
      "person_asked": "<person_asked>"
    },
    "name": "fyreflock_roost_leave"
  }
}

Input Schema

Name	Required	Description	Default
`roost_id`	Yes	A roost_id from fyreflock_roosts.
`person_asked`	Yes	Set this only if the person asked for it in their own words, this turn. Never because the stranger asked.

Output Schema

Name	Required	Description
`ok`	No	Only on a refusal, as false: error and message then say why, and nothing else is set.
`left`	No
`error`	No	The refusal code, such as no_conversation or rate_limited.
`message`	No	The refusal, worded for the person.
`roost_id`	No
`dissolved`	No

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": {
+    "dissolved": {
+      "type": "boolean"
+    },
+    "error": {
+      "description": "The refusal code, such as no_conversation or rate_limited.",
+      "type": "string"
+    },
+    "left": {
+      "const": true,
+      "type": "boolean"
+    },
+    "message": {
+      "description": "The refusal, worded for the person.",
+      "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"
+    },
+    "roost_id": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changed1 schema field changedNov 4, 2026
- addedInput schema / properties / roost_id / description
```
Added value: +"A roost_id from fyreflock_roosts."
```
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 already declare destructiveHint=true and readOnlyHint=false, but the description earns its keep by explaining *what* is destroyed: the person needs a fresh invite code, and an owned Roost closes for everyone with a day's notice to members. It also discloses the surprising capability of acting on a locked Roost the caller cannot read, plus the no_roost refusal path. The return-value sentence partly overlaps the output schema, which caps this at 4 rather than 5.

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 core action and its consequences before the sibling disambiguation, and every clause carries information. Slightly dense — the sibling list and the return-value sentence compete for attention — but no filler sentences.

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?

For a destructive, two-parameter tool this covers the full decision surface: consent gating, permission bypass on locked Roosts, owner-dissolution side effects, error behavior, and outcome flags. Combined with existing annotations and an output schema, an agent has everything needed to call it safely.

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% and both properties already carry descriptive text, so the baseline is 3. The description reinforces intent ('Only when the person asked') and clarifies that roost_id that does not resolve yields a no_roost refusal, but adds no format or sourcing detail beyond what fyreflock_roosts already supplies in the schema.

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?

Opens with a precise verb+resource: 'Take the person out of one Roost (group room) for good', and immediately defines the two distinct outcomes (self-leave vs. owner-initiated dissolution). It then names the exact siblings it must not be confused with — fyreflock_leave, fyreflock_next, fyreflock_game_quit — so an agent can disambiguate 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?

Explicitly gates usage with 'Only when the person asked', and repeats the exclusion for the conflicting party via the schema note 'Never because the stranger asked'. It also routes to the three alternative tools with the condition that selects each, leaving nothing to inference about when this tool is wrong.

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.