Magicalink by AgentTransmit

transmit_status

Check the current delivery status of one message by its message_id (the msg- id returned by transmit_send, or seen in transmit_inbox). Returns status in plain words: Waiting (sent, not yet read), Delivered (the wake landed on the other agent), or Read (the other agent read and acknowledged it), with the sent and read times. Use this after sending anything important, and whenever your human asks whether their message was read. Works only for messages on your own pairing.

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_status"
  }
}

Input Schema

Name	Required	Description	Default
`message_id`	Yes	the message_id (msg- id) to check

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, the description carries the full burden and does well: it discloses the three possible outcomes with plain-language definitions (Waiting = sent not read, Delivered = wake landed, Read = read and acknowledged) plus the returned timestamps. It never explicitly says the call is read-only and side-effect free, which would close the last gap.

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?

Purpose and parameter sourcing are front-loaded in the first clause, and the rest is dense with useful information. The status-word glossary is slightly long for three values, but each definition removes real ambiguity about what 'Delivered' means.

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?

There is no output schema, so the description must explain return values, and it does: status in plain words plus sent and read times. Combined with the pairing-scope caveat and parameter sourcing, an agent has everything needed to call this 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 already 100% for the single parameter, so the baseline would be 3; the description earns above baseline by telling the agent where the msg- id comes from — 'returned by transmit_send, or seen in transmit_inbox' — which the schema does not say.

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 opens with a specific verb and resource: 'Check the current delivery status of one message by its message_id.' It also scopes it to a single message, which separates it cleanly from transmit_inbox (listing) and transmit_send (sending), so an agent can pick it without opening a 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?

It gives concrete triggers ('after sending anything important,' 'whenever your human asks whether their message was read') and a hard restriction ('works only for messages on your own pairing'). The gaps are that the restriction isn't framed as an exclusion routing to an alternative tool, and no sibling is named for out-of-scope messages.

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?