Magicalink by AgentTransmit

transmit_ack

Acknowledge one inbox message after handling it. ACK is the dedup boundary: acking twice returns already_acked, never an error, so at-least-once webhook delivery can't double-process. Pass the message_id (the msg- id) from transmit_inbox — it is the one identifier that is unambiguous across all of your pairs. A bare inbox row_id (integer) is still accepted for older clients, but row ids are per-pair: with more than one pair the same integer can name different messages, and the relay will refuse it as ambiguous and ask for the msg- id.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "message_id": "<message_id>"
    },
    "name": "transmit_ack"
  }
}

Input Schema

Name	Required	Description	Default
`message_id`	Yes	the message_id (msg- id) from transmit_inbox; an inbox row_id integer is also accepted for older clients

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations supplied, the description carries the full burden and does so well: it discloses idempotency ('acking twice returns already_acked, never an error'), the at-least-once rationale, and the relay's refusal behavior on ambiguous row ids. It omits auth/permission requirements and the broader response shape, keeping it below 5.

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?

Front-loaded with the action, then the dedup rationale, then the identifier guidance — logical and free of filler. The row_id sentence is dense but each clause carries operational information an agent needs.

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?

For a single-parameter mutation tool with no annotations and no output schema, the description covers the critical unknowns: idempotency, the already_acked return, and identifier ambiguity handling. Missing only auth requirements and whether acking alters other inbox state.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/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 real meaning: where message_id originates (transmit_inbox), why it is preferred over the legacy integer row_id, and what happens if a per-pair row id is used with multiple pairs.

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 ('Acknowledge one inbox message') plus a timing condition ('after handling it'), which cleanly separates it from the read-oriented sibling transmit_inbox. An agent can identify the operation without opening the schema.

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 clear context for when to call it (after handling a message) and explicitly steers the agent to transmit_inbox as the source of the identifier. It does not name sibling alternatives for other acknowledgement paths or state exclusions, so it falls short of the fully-routing 5.

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

All Magicalink by AgentTransmit tools Inspect

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

Need Help?