Skip to main content
Glama

Sonar Connections

by com.sonarconnections
OverviewDiscussionsAdmin

Reply to a message

event_reply

Sends one message, in the person's own words, into a conversation they already have with somebody they connected with at an event. Needs a personal connector token, text, and firstName or chatId as event_inbox gave them. It is delivered when the call returns and cannot be unsent. Only into the caller's own conversation (else NOT_PARTICIPANT); a name matching two conversations returns AMBIGUOUS_NAME and sends nothing; RATE_LIMITED means too fast. ok:true says nothing about a reply.

Input Schema

NameRequiredDescriptionDefault
textYesThe message in the person's own words, up to 1000 characters. It is sent as given.
chatIdNoOptional conversation id from event_inbox.
firstNameNoOptional first name from event_inbox.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / chatId / description
      Previous value: -"Optional. The id of the conversation, as an event_inbox thread row gave it. When both this and firstName are sent, this one is used."New value: +"Optional conversation id from event_inbox."
    • changedInput schema / properties / firstName / description
      Previous value: -"Optional. The first name of the person to answer, as an event_inbox thread row spelled it, matched against the caller's own conversations only. Two matches return AMBIGUOUS_NAME and nothing is sent."New value: +"Optional first name from event_inbox."
  2. Changed3 schema fields changed
    • changedInput schema / properties / chatId / description
      Previous value: -"OPTIONAL. The id of the conversation to send into, exactly as an event_inbox thread row gave it. Never construct one. Pass this OR firstName, not both; passing both uses this one."New value: +"Optional. The id of the conversation, as an event_inbox thread row gave it. When both this and firstName are sent, this one is used."
    • changedInput schema / properties / firstName / description
      Previous value: -"OPTIONAL. The FIRST NAME of the person to answer, exactly as an event_inbox thread row spelled it. Matched against the caller's OWN conversations only. Two matches come back AMBIGUOUS_NAME and NOTHING IS SENT, and you ask which one they mean rather than choosing: there is no way to unsend a message to the wrong person."New value: +"Optional. The first name of the person to answer, as an event_inbox thread row spelled it, matched against the caller's own conversations only. Two matches return AMBIGUOUS_NAME and nothing is sent."
    • changedInput schema / properties / text / description
      Previous value: -"REQUIRED. The message, in the PERSON'S OWN WORDS, up to 1000 characters. Send what they said: do not tidy it, do not shorten it, do not improve it and never invent one. If they have not said what to send, ask them instead of calling this."New value: +"The message in the person's own words, up to 1000 characters. It is sent as given."
  3. Added

TDQS

A4.7/5.0
Behavior5/5

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

The description adds substantial behavior beyond annotations: delivery is synchronous and cannot be unsent, only the caller's own conversation is allowed, and specific error codes such as NOT_PARTICIPANT, AMBIGUOUS_NAME, and RATE_LIMITED explain failure modes. It also notes that `ok:true` does not imply a reply, which is valuable operational context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: it states the action, required inputs, irreversibility, scope restriction, and error semantics without unnecessary filler.

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 non-idempotent send operation with no output schema, it covers the essential context an agent needs: input source, immediate delivery, irreversibility, participant restriction, ambiguity handling, and rate limiting.

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%, so the baseline is 3. The description still adds meaningful semantics by saying `firstName` or `chatId` should come from event_inbox and that `text` must be the person's own words, though the connector token is not present in the schema.

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 uses a specific verb and resource: it sends one message into an existing event conversation. It also distinguishes the action from starting a new conversation by requiring a conversation the caller already has and referencing event_inbox-provided identifiers.

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 clear usage context: call this to reply into an existing conversation, using `firstName` or `chatId` from event_inbox. It also states the caller's own conversation restriction and maps failures to specific conditions, though it does not explicitly compare against the sibling event_say_hello.

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

All Sonar Connections toolsInspect
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