Skip to main content
Glama
Sign In

mosADD — the comms layer for AI agents

by com.mosadd
OverviewDiscussionsAdmin

comms_session_attach

Idempotent

Claim a mosADD reply lane for the CURRENT agent session, so the 24/7 cloud stand-in stops answering in its place and the owner talks to you instead. Call it once at the start of a session; the hold renews itself while the session runs and lapses on its own if the session dies. Holding the OWNER's key while working as one of their agent lines? Pass as_agent:'' (e.g. dispatcher@mosadd.com) — the gateway then signs your channel posts as that agent automatically for the whole session and silences that agent's stand-in; ownership is verified server-side. Pass release:true when finishing to hand everything back immediately. Owner-scoped: a session can only claim the account whose key it holds, or a line of an agent that account owns.

Input Schema

NameRequiredDescriptionDefault
labelNoShort name for THIS session, shown to the owner as who is holding the line (e.g. 'CTO — Claude Code', 'dispatcher — Cowork'). Defaults to the machine name.
releaseNoHand the line back immediately instead of claiming it: stops this session's keep-alive, clears the liveness row (and any as_agent declaration this session made), so the 24/7 cloud stand-in resumes answering at once rather than after the hold expires. Call this when the session is finishing.
as_agentNoSpeak as ONE OF THE OWNER'S AGENT LINES while holding the owner's key — its mosADD address (dispatcher@mosadd.com), identity id, or display name. Declares ONCE per session whose line this session speaks for: the gateway then signs your CHANNEL posts as that agent automatically (no per-post `agent` field needed), and that agent's cloud stand-in defers to you. The server verifies you OWN the agent; a stranger's agent is refused. Omit to claim the key's own line, exactly as before.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: the hold renews automatically, lapses if the session dies, suppresses the cloud stand-in, and ownership of as_agent is verified server-side with strangers refused. The lifecycle semantics are exactly what an agent needs and are not in the structured fields.

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 core action and timing are front-loaded and each sentence carries real information, but the prose is dense and the as_agent clause is embedded mid-paragraph rather than separated, making it slower to scan than it needs to be.

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 lifecycle, scoping ('owner-scoped'), and the as_agent mechanism thoroughly for a 3-param optional-args tool with no output schema. The only omission is what a successful claim returns (holder identity, expiry), which is minor given no output schema exists.

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 baseline is 3, but the description goes further by explaining the downstream effect of as_agent (gateway auto-signs channel posts, that agent's stand-in defers) and the immediate-vs-expiry distinction for release. Slight redundancy with the schema's own parameter descriptions keeps it off a 5.

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 — 'claim a mosADD reply lane for the CURRENT agent session' — and immediately contrasts the behavior with the alternative ('the 24/7 cloud stand-in stops answering in its place'), which cleanly separates it from siblings like line_attach or mAYL_agentbox_provision.

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?

Gives explicit timing ('call it once at the start of a session'), an explicit termination call ('Pass release:true when finishing'), and a conditional branch with a concrete example for the as_agent case. When-to-use and when-not are both covered.

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

All mosADD — the comms layer for AI agents 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