Gemmein

Reply to a customer

inbox_reply

Asks the founder to approve one reply to a customer inside an existing Inbox conversation (threadId from live_inbox): the approval page in their browser shows the exact text and the customer it goes to (a browser approval; no emailed code is asked for a reply); approving it sends it, once (live_action_status with wait: true reads the outcome) — plain text, to that conversation's customer only (the recipient is the conversation's own, fixed by Gemmein; nothing in the text changes it), from the app's own support address, exactly as the founder's reply from the dashboard (their reply template, threaded under the customer's mail). Nothing is sent before the founder approves it. It never emails anyone else and never starts a conversation. Needs the live:inbox_reply grant — its own line on the Approve page. Refused with nothing sent: when the customer's email didn't pass DMARC — AI replies go only to senders whose email passes DMARC; the founder can reply to anyone (inbox_unauthenticated); after an automatic message (an auto-reply, a bounce, list mail — inbox_auto_reply), after 3 AI replies in a row with no answer from the customer (inbox_reply_cap), while the customer's last message can't be read (inbox_unreadable), past 10 AI replies a day in one conversation (inbox_thread_limited) or 5 an hour to one address (inbox_recipient_limited), and past 60 an hour per connection or 300 per app (inbox_reply_limited). It reaches Live's customers' and strangers' conversations. Each approved reply sends one email; live_inbox with the threadId reads the conversation it answers. The reply shows in the dashboard as sent by the AI and is on the founder's Logs. Returns the approval link for the founder and a handle for live_action_status. This is what a founder may call answering a customer's message.

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": {
      "threadId": "<threadId>",
      "text": "<text>"
    },
    "name": "inbox_reply"
  }
}

Input Schema

Name	Required	Description	Default
`text`	Yes	the reply, plain text, 1–10,000 characters
`threadId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 18, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only flag readOnly=false, openWorld=true, idempotent=false, destructive=false; the description goes far beyond them, disclosing the browser-approval gate, send-once semantics, the fixed recipient and sending address, the required live:inbox_reply grant, DMARC gating, and concrete rate limits (10/day, 5/hour, 60/hour, 300/app). It also states nothing is sent before approval and never emails anyone else. This is exactly the behavioral context annotations cannot carry, and nothing contradicts them.

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?

Purpose and key constraints are front-loaded, but the body is a dense run of nested parentheticals that restates the approval-then-send flow several times and includes tangential claims ('It reaches Live's customers' and strangers' conversations'). Every clause is informative yet hard to scan; restructuring into short, ordered sentences would earn full marks.

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?

With no output schema the description supplies the returns (approval link plus a handle for live_action_status), the follow-up tool (live_action_status with wait: true), failure taxonomy, grant and rate-limit boundaries, and how the send appears in the dashboard and Logs. An agent has everything needed to call and interpret 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?

Schema coverage is only 50% (threadId is undocumented there), but the description supplies its provenance ('threadId from live_inbox'), that it names an existing conversation, and that the recipient is fixed by the conversation rather than the text. The text parameter's length bound comes from the schema, so the description's added value is real but partial.

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 (approve one reply to a customer inside an existing Inbox conversation) and pins the exact inputs (threadId from live_inbox, plain text). It is unmistakable against siblings such as live_inbox, inbox_auto_reply, and inbox_unauthenticated, which are named explicitly.

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?

Says plainly that 'this is what a founder may call answering a customer's message' and enumerates the refusal conditions with the sibling tool for each (inbox_unauthenticated, inbox_auto_reply, inbox_reply_cap, etc.). It stops short of naming a same-purpose alternative tool, but the when-to-use picture is clear.

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

All Gemmein tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.