Skip to main content
Glama

Hands Conversations

alterlab_hands_conversations

A conversation has a counterparty, a channel (email, web_chat, ticket_thread or form_reply), a goal, limits (max price, deadline, items not to concede), a persona (always the user, disclosed as acting on their behalf) and a message budget. Voice calls are not supported. action=create starts one; list, get and messages read. action=inbound records counterparty text as untrusted content: it is read for offers, refusals, resolution and human-needed signals and never changes the goal or limits. action=draft checks an outbound message: an unsupported claim or a commitment over the limits is blocked, one the policy does not auto-allow asks for approval (action=approve with content_hash), an allowed one returns the dispatch payload to send as the user's own mailbox or an owned alias (any other sender is refused). action=dispatch returns an authorized message's payload; action=report records the send result. Replies are paced and deduplicated; the conversation stops on goal reached, deadline, refusal, a human-needed signal, an exhausted budget or action=stop (final).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "alterlab_hands_conversations"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyNoInbound or draft: the message text
goalNoCreate: kind (deal or resolve) and text
limitNoMessages: rows to return
actionNoDefault list
claimsNoDraft: bindings for each claim (claim plus fact, limit, quote or user_authored)
limitsNoCreate: max_price, currency, deadline (ISO time), no_concede (items never to concede)
senderNoCreate: sending address; must be your own mailbox or an owned alias
sourceNoInbound: where the text came from
channelNoCreate: how the conversation runs
outcomeNoReport: the connector result
personaNoCreate: name and disclose_agent (default true)
min_gap_sNoCreate: minimum seconds between sends (default 60)
message_idNoRequired for approve, dispatch and report
thread_refNoCreate: provider thread id to reply into
external_idNoInbound: provider message id; Report: sent message id
content_hashNoApprove: content_hash of the held draft
counterpartyNoCreate: name (optional) and address (email address, chat or ticket URL)
follow_up_textNoCreate: the follow-up message
message_budgetNoCreate: most messages to send (default 10)
conversation_idNoRequired for every action except create and list
follow_up_delay_sNoCreate: seconds before the follow-up is sent if unanswered

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior3/5

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

The description adds real behavioral context beyond the annotations – inbound text is untrusted and cannot change goal or limits, draft blocks unsupported claims and over-limit commitments, approval requires content_hash, the sender must be the user's own mailbox or an owned alias, and replies are paced/deduplicated. However, it does not explain the response shape of list/get/messages or error conditions, and the 21-parameter surface means several behaviors (follow-up timing, thread_ref usage) remain undisclosed.

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?

It is a single dense paragraph that front-loads the domain model before the action list, and nearly every clause carries information. The density of semicolon-separated action clauses makes scanning harder than necessary, and a small amount of structural formatting would improve it.

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 multiplexed 21-parameter tool with no output schema, the description covers the domain model, each action, safety rules (untrusted inbound, blocked claims, approval flow), and all stop conditions. What it omits is the shape of list/get/messages results and the error behavior on refused senders or expired approvals, which an agent needs to interpret responses.

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 the baseline is 3, but the description earns an extra point by giving semantic weight to parameters the schema only labels: persona is 'always the user, disclosed as acting on their behalf', sender must be an owned alias, limits include items not to concede, and content_hash ties approval to a held draft. It still does not map the remaining parameters (thread_ref, source, outcome) to behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise domain model (counterparty, channel, goal, limits, persona, message budget) and enumerates every action with a specific verb: create starts, list/get/messages read, inbound records, draft checks, approve holds, dispatch returns the payload, report records, stop finalizes. It never names a sibling tool or explains why it is not one of the many hands_* alternatives, which is the only gap.

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?

Each action's role is stated ('action=create starts one; list, get and messages read'), and 'Voice calls are not supported' is an explicit exclusion. What is missing is conditional guidance on choosing between this tool and the hands_* siblings, or when an agent should use list vs. messages rather than inferring it from names.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.