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

TDQS

A4.5/5.0
Behavior5/5

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

The description goes far beyond the annotations. It discloses idempotency nuances, guaranteed timeout delivery, free billing, write-only notify_address, plain-text barrier_id storage, and the fact that out-of-roster signals do not count. This is exactly the behavioral context an agent needs, and it does not contradict the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is information-dense and front-loaded, but it is also bloated: 'FREE' appears twice, the all-caps warning is long, and some clauses repeat the same idea. It is structured enough to follow, but it would benefit from tightening.

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?

For a 9-parameter mutation tool with no output schema and minimal annotations, this description is exceptionally complete. It covers lifecycle, idempotency, timeout behavior, billing, authentication, and notification semantics, leaving little ambiguity for an agent deciding whether and how to call it.

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?

The schema already covers all 9 parameters at 100%, and the description adds meaningful semantics on top: min_count/default/expected_count interaction, deadline_seconds bound to TTL, write-only notify_address, and the plain-text nature of barrier_id. Not every parameter is re-explained in prose, but the key nuances are there.

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?

Name and title clearly identify the action: opening a join point for fan-out work. The description adds the specific 'last one to finish wakes the joiner' semantics and distinguishes the tool from siblings like barrier_signal and barrier_status by focusing on creation and lifecycle reuse.

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?

The description gives rich contextual guidance: when to fan out work, when to use min_count/deadline_seconds, what happens on timeout, and how reusing a barrier_id creates new generations. It does not explicitly name alternatives or state 'use X instead of Y', but the sibling names plus this context make the intended usage clear.

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.

TDQS

A4/5.0
Disambiguation5/5

Every tool targets a clearly distinct mechanism—barriers, budgets, checkpoints, claims, heartbeats, inboxes, leases, work queues, etc. Even closely related pairs like claim/complete, work_done/inbox_ack, and barrier_status/work_status are explicitly differentiated in their descriptions, so an agent can reliably select the right tool.

Naming Consistency4/5

The dominant pattern is object_verb (e.g., checkpoint_get, work_push, seen_add, lease_release), which is consistent and readable. A few single-word verbs (claim, complete, send) and noun-only names (resume_packet, retry_state, whoami) break the pattern, but they are few and still intuitive.

Tool Count2/5

With 33 tools, the surface is well beyond the 25-tool threshold for 'too many' and will feel heavy for agents to explore, even though the tools are organized into subdomains. The scope is broad, but the sheer number makes the server less approachable and increases the chance of misselection.

Completeness5/5

The tool set provides thorough lifecycle coverage across its domains: checkpoints get/put, work queue push/take/done/fail/status, inbox poll/ack/nack/schedule, lease acquire/renew/release, barrier create/signal/status, dedup add/check, watermark get/set, retry state, budget check/record, and idempotency claim/complete. There are no obvious dead ends or missing essential operations.

Resources