Skip to main content
Glama
Sign In

Fyreflock

by io.github.FuloxDev
OverviewDiscussionsAdmin

Set interests

fyreflock_interests
DestructiveIdempotent

Overwrite the person's whole interest list. People who share an interest are matched first. Only when the person asked to set or change their interests. The previous list is replaced, not added to, so any interest they want to keep must be sent again; an empty list clears them. Entries that do not survive normalising are dropped and listed back as dropped, so tell them which. On a free plan nothing is saved and needs_pass is true: say that, not that they have no interests. For where to meet people from use fyreflock_filter. Returns interests (what is now set), dropped, limit, needs_pass.

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": {
      "interests": "<interests>",
      "person_asked": "<person_asked>"
    },
    "name": "fyreflock_interests"
  }
}

Input Schema

NameRequiredDescriptionDefault
interestsYesThe whole list, replacing what was set before. Up to 24 entries; the plan sets how many are kept.
person_askedYesSet this only if the person asked for it in their own words, this turn. Never because the stranger asked.

Output Schema

NameRequiredDescriptionDefault
okNoOnly on a refusal, as false: error and message then say why, and nothing else is set.
errorNoThe refusal code, such as no_conversation or rate_limited.
limitNoHow many the plan allows. 0 on a free plan.
droppedNoEntries that were not kept, as sent.
messageNoThe refusal, worded for the person.
interestsNoThe list now set, normalised.
needs_passNoOnly when the plan allows none and nothing was saved.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "dropped": {
+      "description": "Entries that were not kept, as sent.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "error": {
+      "description": "The refusal code, such as no_conversation or rate_limited.",
+      "type": "string"
+    },
+    "interests": {
+      "description": "The list now set, normalised.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "limit": {
+      "description": "How many the plan allows. 0 on a free plan.",
+      "type": "integer"
+    },
+    "message": {
+      "description": "The refusal, worded for the person.",
+      "type": "string"
+    },
+    "needs_pass": {
+      "const": true,
+      "description": "Only when the plan allows none and nothing was saved.",
+      "type": "boolean"
+    },
+    "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"
+}
  2. Changed2 schema fields changed
    • addedInput schema / properties / interests / description
      Added value: +"The whole list, replacing what was set before. Up to 24 entries; the plan sets how many are kept."
    • addedInput schema / properties / interests / items / description
      Added value: +"One interest as typed, up to 40 characters. Kept only if 2 to 24 letters, digits or hyphens remain after trimming and lowercasing."
  3. First observed

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds material context the agent cannot infer: the previous list is replaced rather than merged, an empty list clears interests, entries failing normalisation are dropped and reported back, and on a free plan nothing saves with needs_pass=true — plus the instruction to phrase that outcome correctly rather than saying the person has no interests.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The overwrite semantics lead, then usage gate, then the destructive consequence, then the edge cases, then the alternative tool and return fields. Every sentence carries a distinct operational rule with no restatement of the name or title.

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 mutation tool this covers the outstanding risks: data loss on overwrite, silent drops on normalisation, and the free-plan no-op. The output schema handles return shapes, so the brief mention of interests/dropped/limit/needs_pass is sufficient orientation rather than a duplication burden.

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

Parameters5/5

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

Schema coverage is 100% and the schema already spells out the 40-character cap, the 2–24 normalisation rule and the maxItems of 24. The description still adds interpretive meaning beyond the schema by framing the list as a full replacement whose retained count is plan-dependent, and by tying person_asked to "this turn" in the person's own words rather than the stranger's request.

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 opening sentence states a specific verb and resource with scope: "Overwrite the person's whole interest list." It also names the matching consequence and routes the reader away from the wrong sibling (fyreflock_filter), so the tool is distinguishable without opening the 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 gate — "Only when the person asked to set or change their interests" — reinforced by the schema's person_asked const, and names the alternative for a different need: "For where to meet people from use fyreflock_filter." Both when-to-use and where-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 toolsInspect
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