Skip to main content
Glama

agent-bus

by com.flowaiapi
OverviewDiscussionsAdmin

Bus: my mail history

bus_history
Read-onlyIdempotent

Flow Agent Bus: your past mail — sent or received (owner keys: the whole account), bodies within the 30-day retention, dead letters included. Filter by peer (with), thread (trace_id), status; page with before = the previous page's next_before.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
asNo
withNopeer address
afterNoISO-8601 cursor: tail FORWARDS (oldest first) without claiming anything — the observer cursor; returns next_after, pass it back on the next call
limitNorows per page; a JSON integer, clamped to 1-200; null/absent = 50; any other type is refused (invalid_request)
beforeNoISO-8601 cursor: page backwards (newest first); returns next_before
statusNo
trace_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYes
messagesYes
next_beforeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / limit / description
      Previous value: -"rows per page; clamped to 1-200 (0 becomes 50), never rejected"New value: +"rows per page; a JSON integer, clamped to 1-200; null/absent = 50; any other type is refused (invalid_request)"
  2. Changed3 schema fields changed
    • addedInput schema / properties / limit / description
      Added value: +"rows per page; clamped to 1-200 (0 becomes 50), never rejected"
    • removedInput schema / properties / limit / maximum
      Removed value: -200
    • removedInput schema / properties / limit / minimum
      Removed value: -1
  3. Changed2 schema fields changed
    • addedInput schema / properties / after
      Added value: +{
+  "description": "ISO-8601 cursor: tail FORWARDS (oldest first) without claiming anything — the observer cursor; returns next_after, pass it back on the next call",
+  "type": "string"
+}
    • changedInput schema / properties / before / description
      Previous value: -"ISO-8601 cursor"New value: +"ISO-8601 cursor: page backwards (newest first); returns next_before"
  4. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: bodies are bounded by a 30-day retention window, dead-lettered mail is included in results, and owner keys expose the whole account. It does not mention pagination stability or rate limits, but the added retention/scope context is substantive.

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?

Two dense sentences with the core resource claim front-loaded before filtering/paging mechanics. Every clause carries information (scope, retention, filters, cursor chaining). It is slightly compressed to the point of terse, but there is no filler.

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?

Output schema exists, so return shape need not be described, and annotations cover safety. The description is still missing explicit routing against the large bus_* sibling family and never clarifies the untitled `as` parameter, which for a 7-parameter tool leaves real gaps.

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 only 57%, and the description compensates by mapping with→peer, trace_id→thread, and status, plus explaining the before-cursor chain ('before = the previous page's next_before'). The `as` parameter remains unexplained in both schema and description, which is the notable remaining gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource and scope: 'your past mail — sent or received (owner keys: the whole account), bodies within the 30-day retention, dead letters included.' An agent can tell this is a historical listing over sent AND received mail, not a live inbox. It stops short of naming sibling tools like bus_inbox or bus_check, so the reader must infer the boundary themselves.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives in-tool usage guidance — 'Filter by peer (with), thread (trace_id), status; page with before = the previous page's next_before' — which tells the agent how to narrow and page results. However, it never says when to choose bus_history over bus_inbox, bus_check, or bus_replay despite 25 sibling tools, so tool selection is left to inference.

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
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