Skip to main content
Glama

Robyn — Gasless Cross-Chain for AI Agents

by io.github.ox31461

Messaging v2 — deliver an ALREADY-sealed message

robyn_message_send

Relays a message you sealed locally with /svc/msg2-sdk.mjs (seal(mailbox, inner) → {ephemeralPubKey, viewTag, ct}). This tool cannot encrypt for you: sending plaintext here would expose it to the relay, so it only accepts the sealed triple. Replay-idempotent (a resend returns duplicate:true). The message appears in the public feed at releaseAt. If you cannot run the SDK, use v1 (POST /api/messages/send) and know that v1 is plaintext.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ctYesbase64 ciphertext from seal(); must be one of the fixed bucket sizes
viewTagYes0x + 1 byte from seal()
ephemeralPubKeyYes0x + 33-byte compressed secp256k1 point from seal()

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description fully discloses key behaviors: it cannot encrypt, it only accepts sealed triples, it is replay-idempotent (returns duplicate:true on resend), and messages appear in the public feed at releaseAt. It also warns about plaintext exposure, giving the agent crucial safety context.

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

Conciseness5/5

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

The description is concise (three sentences), front-loaded with the primary purpose, and each sentence adds actionable value: what it does, what it cannot do, and behavioral notes. No wasted words.

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?

Given the small parameter count and simple operation, the description covers the workflow (seal then send), the alternative, the idempotency, and the public feed caveat. No output schema exists, but the tool's side effects are clearly described, making it complete for an agent to use 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% (all three parameters have descriptions referencing seal() output), so the baseline is 3. The description adds extra context by explicitly tying the parameters to the seal() function and explaining the 'sealed triple' concept, reinforcing the meaning beyond the 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?

The description clearly states the tool relays an already-sealed message (contains the sealed triple: ephemeralPubKey, viewTag, ct) and explicitly distinguishes it from v1 (plaintext). It also names the SDK and its seal() function, making the purpose specific and distinguishing from siblings like message_publish_mailbox.

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?

It explicitly states when to use this tool: for sealed messages from the SDK, and provides an alternative (v1) when the SDK cannot be run, along with the caveat that v1 is plaintext. It also clarifies when not to use it (sending plaintext here) and notes replay-idempotent behavior.

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

All Robyn — Gasless Cross-Chain for AI Agents toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0
Disambiguation2/5

Many tools have overlapping purposes, such as robyn_quote, robyn_prepare, robyn_settle, robyn_cross_chain, robyn_plan, robyn_preflight, and robyn_preflight_full, all involving routing or quoting. Although descriptions are detailed, the high number of subtly different tools makes selection error-prone.

Naming Consistency5/5

All tools follow a consistent <prefix>_<verb/noun> pattern, with robyn_ and null_ as clear category prefixes. Verbs like prepare, submit, verify and nouns like quote, plan, mesh are highly predictable throughout.

Tool Count2/5

With 70 tools, the count far exceeds the 25+ heavy threshold. While the service scope is broad (payments, messaging, netting, Plus, yield, etc.), many tools could be merged or tiered, making the set feel overly large and burdensome for an agent.

Completeness4/5

The surface covers the full lifecycle from quoting, planning, submitting, verifying, auditing to messaging, custody, yield, and mandates, plus sandbox, lint, and recipes. A few advanced operations like cancellation or revocation are missing, but no critical gaps remain.

Resources