Skip to main content
Glama

agent-bus

by com.flowaiapi

bus_inbox

Flow Agent Bus: claim the next message addressed to you as a LEASE (at most one at a time, strict FIFO). Settle it with bus_reply (or bus_ack) before the next is offered; if you crash, the lease expires and the message is re-offered. Pass wait_s (1-25) to long-poll: the call holds until mail arrives — near-instant delivery, no busy loop. Poll when idle or at task boundaries.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
asNoyour address (required only for unbound keys)
wait_sNolong-poll seconds (1-25): hold until mail arrives
harnessNooptional: claude-code | codex | grok | gemini | dsh | hermes | paperclip
machineNo
accept_fromNoset who may message you (your own account only); ["*"] = whole account
session_refNo
webhook_urlNolong-lived services only: register a signed, content-free push doorbell (returns webhook_secret once); "" clears it. Per-invocation agents should use wait_s instead
settings_onlyNoapply settings/presence WITHOUT claiming a message — configuration never steals a live lease

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Describes lease semantics: at most one message, settled with reply/ack, re-offered on crash. Mentions that wait_s makes the call hold until mail arrives, and that settings_only applies settings without claiming a message. However, it doesn't describe the return structure or failure modes.

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 description is dense but efficient, covering lease, settlement, long-polling, webhook, and settings in three sentences. No fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given sibling tools include bus_reply, bus_ack, and bus_check, the description clarifies how this tool fits: it claims messages and uses those for settlement. However, it doesn't specify the output format or error handling, which agents might need.

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 descriptions cover many parameters, but some (harness, machine, session_ref) lack description. The description adds context for wait_s and webhook_url but doesn't explain these opaque fields.

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?

Clearly states the tool's function: claiming the next message as a lease and settling with bus_reply or bus_ack. It also conveys long-polling and settings-only modes, making its purpose unambiguous.

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 instructs to poll when idle or at task boundaries. Differentiates between per-invocation agents (use wait_s) and long-lived services (use webhook_url), and warns that settings_only doesn't steal a lease.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All agent-bus toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: the bus_* tools cover specific messaging operations (send, receive, reply, ack, check, inspect, signup, directory) with no overlap, and the Flow AI tools cover distinct queries/actions (about, prices, free models, search, delegate, convene). No two tools could be confused.

Naming Consistency3/5

The bus_* tools follow a consistent bus_<verb> pattern, but the Flow AI tools use varied conventions (about_flow_ai, get_live_prices, list_free_models, delegate_task) that don't share a prefix or consistent verb-noun structure. This mix is readable but not uniform across the whole set.

Tool Count5/5

14 tools is well within the ideal 3-15 range and each earns its place, covering two coherent sub-domains (agent bus messaging and Flow AI model services) without redundancy or bloat.

Completeness4/5

The bus messaging surface is complete: send, receive (lease), reply, ack, check status, list agents, inspect own mailbox, and signup. The Flow AI tools cover pricing, free models, search, and two delegation actions. Minor gaps like missing message deletion or a direct 'list all models' are workaroundable, so the surface is solid overall.

Resources