hunchful

Send or draft into a conversation

send_to_conversation

Send something INTO one of the person's conversations — a friend, a group chat, the family/household chat — e.g. "summarize this for Elin" or "tell the family dinner is at 6". to is a name, @handle, group name or conversationId; it's matched against the person's OWN conversations and never guessed: if several fit you get status 'ambiguous' with candidates — ask the person which one, then call again with that conversationId. The message is labelled "via " for everyone, and a line lands in the person's private Min AI panel for that chat (with Undo for 15 minutes).

CONSENT: these are the person's PRIVATE conversations, so this always saves a DRAFT they send with one tap (they get a notification) — you never send in their name here; the result says so, tell them. A conversation that includes someone under 18 is a draft too, always. Same rules as a message typed in the app (blocks, read-only chats, moderation). Not end-to-end encrypted: never include ID numbers, passwords/PINs, bank/card or health details.

Input Schema

TableJSON Schema

Name	Required	Description
`to`	Yes	Who/where: a friend's name or first name, an @handle, a group's name, or a conversationId. Example: "Elin"
`mode`	No	Kept for older callers: a private chat always gets a draft the person sends. "draft" says so explicitly.
`text`	Yes	The message, in the person's voice — plain text; short Markdown like bold and lists is fine. Example: "Hej Elin! Kort sammanfattning av artikeln: …"
`about`	No	What this is, in a few words, for the person's Min AI record. Example: "a summary of the article"
`links`	No	Optional links, added under the text.
`replyTo`	No	Answer one message in the chat (shown quoted above yours, like the app's Svara): its id from read_conversation or read_unread. Pass `to` as that conversation's conversationId. Example: "Xk3p9QwErT2yUi8oPa1s"

Output Schema

TableJSON Schema

Name	Required	Description	Default
`to`	Yes
`note`	Yes
`status`	Yes
`draftId`	No
`messageId`	No
`undoUntil`	No
`candidates`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 16, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false) by disclosing that this always saves a draft the person sends with one tap, that a notification and an Undo window of 15 minutes exist, that messages are labelled "via <app name>", that under-18 conversations force drafts, and that blocks/read-only chats/moderation apply. It also warns the channel is not end-to-end encrypted and lists content that must never be included.

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?

Long but front-loaded, with the core action in sentence one and a clearly labelled CONSENT block carrying the constraints. Nearly every sentence adds decision-relevant information, though the density is close to the limit for a tool description.

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?

For a write-shaped tool with annotations and an output schema already present, the description covers the remaining risk surface an agent needs: draft-only behavior, the consent/notification model, ambiguity handling, and content restrictions. Nothing material is missing.

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 description coverage is 100%, so a baseline of 3 applies, but the description adds real semantics the schema does not: `to` is matched only against the person's own conversations, is never guessed, and yields status 'ambiguous' with candidates when several match. The `mode` parameter is left to the schema, which is acceptable since it is documented there.

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?

States a concrete verb and resource: sending/drafting a message INTO a named person's own conversation, with concrete example phrasings. It is clear what the tool does, but it never distinguishes itself from the adjacent siblings send_message and message_group, which appear to cover overlapping channel/group targets.

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 trigger examples ("summarize this for Elin", "tell the family dinner is at 6") and an explicit recovery procedure for the ambiguous-target case: ask the person, then re-call with the conversationId. It stops short of stating when to prefer a sibling such as send_message or message_group instead.

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

All hunchful tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.