Skip to main content
Glama
Sign In

Fyreflock

by io.github.FuloxDev
OverviewDiscussionsAdmin

Video call from the chat box

fyreflock_app_video

Invites the person on the other end of the chat box to a video call on fyreflock.com, or answers the invite waiting for this person. With no answer it sends the invite, which also counts as the sender saying yes. The box's version of fyreflock_video: a model relaying for the person uses fyreflock_video. Called only by the box with its box_key. Refused with no_invite when answer is given and nothing is waiting, no_conversation when nobody is on the other end, cannot_start when the call could not be set up. Returns the whole box state, the same shape fyreflock_app_wait gives; the call itself runs on fyreflock.com in a browser once both have said yes.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "fyreflock_app_video"
  }
}

Input Schema

NameRequiredDescriptionDefault
answerNoAnswers the invite waiting for this person. Leave it out to send an invite.
box_keyNoThe key the chat box received in fyreflock_open's result _meta. Only the box holds one, so only the box can call this tool.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / answer / description
      Added value: +"Answers the invite waiting for this person. Leave it out to send an invite."
    • changedInput schema / properties / box_key / description
      Previous value: -"Set by the chat box itself."New value: +"The key the chat box received in fyreflock_open's result _meta. Only the box holds one, so only the box can call this tool."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Despite annotations already declaring a non-read-only, open-world, non-destructive operation, the description goes well beyond them: it enumerates the failure modes (no_invite, no_conversation, cannot_start), explains that the invite doubles as consent, and clarifies that the call itself runs in a browser on fyreflock.com rather than through the tool.

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?

The lead sentence front-loads the two modes and the rest is dense with non-redundant detail, so nothing is wasted. The prose is clause-heavy and runs long, which slightly hurts scannability but not accuracy.

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?

With no output schema, the description compensates by saying it returns the whole box state in the same shape as fyreflock_app_wait. Combined with error codes, caller restriction, and the browser handoff, an agent has everything needed to call it correctly.

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, but the description adds real meaning: sending an invite "also counts as the sender saying yes," which is a semantic consequence the schema does not convey. It also reinforces that box_key belongs only to the box.

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 description names a specific verb and resource (invite to a video call / answer a pending invite) and explicitly positions itself against the sibling: "The box's version of fyreflock_video: a model relaying for the person uses fyreflock_video." An agent can distinguish the two without opening either 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 states both modes and the condition that selects each: omit the answer to send an invite, supply it to answer a waiting one. It also names the caller restriction ("Called only by the box with its box_key") and the alternative tool, leaving little to inference.

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