Skip to main content
Glama

ComOS Federation Gateway

by com.comos-federation
OverviewDiscussionsAdmin

federation_journal_read

Read-onlyIdempotent

Replay your agent journal oldest→newest (CO 230-001). Call this at the start of a cold session — with only your tenant id — to reconstruct your intent and resume where you left off. On a tenant whose workflow runs journal themselves, add exclude_tags ["act-record"] to replay the reasoning without the run trail; the reply's excluded says how many entries that left out. Pairs with federation_journal_append. Requires journal:read on your federation OAuth bearer (standard manager grant carries it), and you can only replay tenants your manager root owns. Returns: The journal entries oldest→newest (up to limit). Example: call federation_journal_read with arguments {"tenant_id":"<tenant_id>"}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNoKeep only entries carrying ANY of these tags, applied before limit (e.g. ["ruling"], or ["act-record"] for the run trail alone).
limitNoMax entries (default 200, max 1000), oldest→newest.
tenant_idYesYour tenant id whose journal to replay.
exclude_tagsNoLeave out entries carrying ANY of these tags, applied before limit. ["act-record"] replays the reasoning only — the entries workflow runs write about themselves are left out, and the reply's `excluded` says how many.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / exclude_tags
      Added value: +{
+  "description": "Leave out entries carrying ANY of these tags, applied before limit. [\"act-record\"] replays the reasoning only — the entries workflow runs write about themselves are left out, and the reply's `excluded` says how many.",
+  "items": {
+    "maxLength": 100,
+    "type": "string"
+  },
+  "maxItems": 20,
+  "type": "array"
+}
    • addedInput schema / properties / tags
      Added value: +{
+  "description": "Keep only entries carrying ANY of these tags, applied before limit (e.g. [\"ruling\"], or [\"act-record\"] for the run trail alone).",
+  "items": {
+    "maxLength": 100,
+    "type": "string"
+  },
+  "maxItems": 20,
+  "type": "array"
+}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), but the description adds behavior they cannot express: the journal:read OAuth scope requirement, the manager-root ownership restriction limiting which tenants can be replayed, and the reply's `excluded` count reporting dropped entries.

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?

Single dense paragraph, but front-loaded with the core action and ordered from purpose → conditional usage → prerequisites → return → example. No filler sentences, though the packing makes it heavier than ideal for scanning.

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 must carry return semantics—and it does ('Returns: The journal entries oldest→newest (up to limit)'). Combined with auth scope, ownership limits, and a concrete call example, an agent has everything needed to invoke 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. The description goes beyond it by explaining the semantic intent of exclude_tags (replay reasoning without the run trail) and by disclosing the `excluded` reply field, which is not derivable from the input schema alone.

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 ('Replay your agent journal oldest→newest') with an explicit ordering/scope. It also names its sibling counterpart ('Pairs with federation_journal_append'), so an agent can distinguish the read side from the write side 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?

Explicit when-to-use: 'Call this at the start of a cold session... to reconstruct your intent and resume where you left off.' Also gives a conditional variant ('On a tenant whose workflow runs journal themselves, add exclude_tags ["act-record"]') and names the completing 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 ComOS Federation Gateway toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources