Skip to main content
Glama

MCPFax Agent Continuity

Open a join point for fan-out work

barrier_create
Idempotent

Fan work out to N agents and have the LAST one to finish wake the joiner. FREE. A BARRIER THAT WAITS FOR ALL N IS A HANG WAITING TO HAPPEN, so stragglers are the normal case here, not an edge case: set min_count and/or deadline_seconds and we fire on whichever comes first, ALWAYS naming the participants that did not report. Exactly ONE envelope is queued to notify_address, carrying every participant's payload; that delivery is billed by the existing inbox_poll rule, so there is no new charge. If nothing has fired by the TTL we queue a barrier_timeout envelope naming the missing participants — a timeout is information and is delivered, never silently dropped. REUSING A BARRIER_ID IS THE NORMAL PATTERN: while a join is still open this call is idempotent and refuses to reset it (created:false), because a retrying agent must not be able to reset a join others are signalling — but once it has fired or timed out, calling barrier_create with the same id opens a NEW GENERATION with your new roster, and that generation gets its own notification. FREE — this tool never charges. Authenticate with Authorization: Bearer , or pass agent_key as an argument if your host cannot set headers. Equivalent HTTP route: POST /v1/barrier/create.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
agent_keyNoYour agent_secret, if your MCP host cannot set the Authorization header. Prefer the header.
min_countNoFire as soon as THIS many have signalled, instead of waiting for all of them. Default: expected_count. Set it lower and a straggler cannot hang the join. Example: '2'.
objectiveNoOptional text carried into every envelope so the joiner knows what it is being woken for. <=2048 chars. Example: 'Roll up the three regional reports'.
barrier_idYesYour name for this join point. Namespace-scoped; stored in plain text so a timeout can name it back to you. Example: 'quarterly-rollup-2026q3'.
ttl_secondsNoHow long the barrier lives before timing out. Default 3600, min 5, max 2592000. Example: '3600'.
participantsNoOptional roster of participant ids. Supply it and every notification names exactly who is missing; omit it and we can only report the shortfall. A signal from outside the roster is recorded but does NOT count toward the threshold. Example: '["a","b","c"]'.
expected_countNoHow many participants you expect. 1..500. Defaults to the length of `participants` when you supply a roster. Example: '3'.
notify_addressYesWhere the completion, deadline or timeout envelope goes. Must be registered. WRITE-ONLY: we queue into it and never read it. Example: 'agent:7k2p.../joins'.
deadline_secondsNoFire at this many seconds from now with whoever has signalled, whether or not min_count was reached. Must be <= ttl_seconds. The notification names who did not report. Example: '600'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / agent_key / examples
      Added value: +[
      +  "the agent_secret that register returned"
      +]
  2. Changed8 schema fields changed
    • addedInput schema / properties / barrier_id / examples
      Added value: +[
      +  "quarterly-rollup-2026q3"
      +]
    • addedInput schema / properties / deadline_seconds / examples
      Added value: +[
      +  600
      +]
    • addedInput schema / properties / expected_count / examples
      Added value: +[
      +  3
      +]
    • addedInput schema / properties / min_count / examples
      Added value: +[
      +  2
      +]
    • addedInput schema / properties / notify_address / examples
      Added value: +[
      +  "agent:7k2p.../joins"
      +]
    • addedInput schema / properties / objective / examples
      Added value: +[
      +  "Roll up the three regional reports"
      +]
    • addedInput schema / properties / participants / examples
      Added value: +[
      +  "[\"a\",\"b\",\"c\"]"
      +]
    • addedInput schema / properties / ttl_seconds / examples
      Added value: +[
      +  3600
      +]
  3. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Goes far beyond the idempotentHint/readOnly annotations by disclosing idempotent retry semantics, new-generation behavior on reuse, timeout envelope delivery, billing via inbox_poll, authentication options, and the exactly-one-enveloe guarantee. No contradiction with annotations.

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?

Dense and front-loaded with the core use case and the straggler warning before lower-level details. The only real flaw is minor redundancy, notably FREE being stated twice, but overall every section earns its place for a complex 9-parameter tool.

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

Completeness4/5

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

Covers the key operational concerns: authentication, billing, timeout behavior, idempotent reuse, and enveloe delivery. The main gap is that there is no output schema and the description only mentions created:false, not the full success return shape, so an agent cannot fully predict the response object.

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 meaningful interaction semantics: min_count and deadline_seconds fire on whichever comes first, participants affect missing-name reporting, outside signals do not count, and reusing barrier_id opens a new generation. This helps an agent reason about parameter combinations beyond the raw schema.

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 (create/open) and resource (a join point/barrier) and explains the fan-out/last-finisher-wakes-joiner model. It plainly distinguishes itself from barrier_signal and barrier_status by focusing on creation and lifecycle semantics rather than signalling or status.

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

Usage Guidelines4/5

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

Gives strong context: this is the tool for fanning out to N agents and being woken when the threshold/deadline is met, with clear guidance to set min_count and deadline_seconds because stragglers are normal. It does not explicitly name sibling alternatives or state when not to use it, so it stops short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources