Fyreflock

Set who they meet

fyreflock_filter

Idempotent

Set which part of the world the person would rather meet somebody from. Only when they asked. Matched at region level, so it is a preference and not a guarantee: when nobody nearby is waiting, Fyreflock widens rather than leaving them staring at a spinner. Applies to the next fyreflock_start, not the current conversation, and stays set until changed. For what they want to talk about use fyreflock_interests; to meet a member of their own Roost pass roost_id to fyreflock_start. Refused with unknown_country when the name is not recognised, and nothing changes. Returns region, label, strict: false.

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": {
      "country": "<country>",
      "person_asked": "<person_asked>"
    },
    "name": "fyreflock_filter"
  }
}

Input Schema

Name	Required	Description	Default
`country`	Yes	A country name or its two-letter code. Matched at region level.
`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.
`error`	No	The refusal code, such as no_conversation or rate_limited.
`label`	No	The region, worded for the person.
`region`	No	The region code the country fell into.
`strict`	No	Always false: it is a preference, never a filter that leaves them waiting.
`message`	No	The refusal, worded for the person.

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"
+    },
+    "label": {
+      "description": "The region, worded for the person.",
+      "type": "string"
+    },
+    "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"
+    },
+    "region": {
+      "description": "The region code the country fell into.",
+      "type": "string"
+    },
+    "strict": {
+      "const": false,
+      "description": "Always false: it is a preference, never a filter that leaves them waiting.",
+      "type": "boolean"
+    }
+  },
+  "type": "object"
+}

Changed1 schema field changedNov 4, 2026
- addedInput schema / properties / country / description
```
Added value: +"A country name or its two-letter code. Matched at region level."
```
First observedNov 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare this is a non-destructive, idempotent write, and the description adds substantial context beyond them: region-level matching is a preference not a guarantee, the system widens rather than leaving the user waiting, the value persists until changed, and it only affects future fyreflock_start calls. The failure mode 'Refused with unknown_country... and nothing changes' is exactly the kind of atomicity disclosure an agent needs.

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 purpose, then constraints, then alternatives, then error behaviour — a sensible priority order with no filler sentences. However the closing 'Returns region, label, strict: false' restates an output schema that already exists, and the run-on colon-chained sentences are denser than necessary.

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 two-parameter write with full schema documentation and an output schema, everything an agent needs is present: the consent gate, timing of effect, persistence, matching semantics, sibling alternatives, and the error case. The return-value sentence is redundant rather than a completeness gap.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description adds genuinely new meaning by specifying that an unrecognised country name is refused with unknown_country and that nothing changes, which ties the country parameter to a concrete error contract. The region-level matching note largely duplicates the schema text, keeping this below a 5.

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 ('Set which part of the world the person would rather meet somebody from') and immediately disambiguates from two siblings: fyreflock_interests for topics and roost_id on fyreflock_start for own-Roost matching. An agent can route correctly without opening another 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 gating condition ('Only when they asked'), names the alternative tools for the adjacent needs, and states when the setting takes effect (next fyreflock_start, not the current conversation). Both when-to-use and when-not-to-use are covered.

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.