Cosend

Ask a teammate for a chat

ask_for_conversation

DestructiveIdempotent

Asks the person who holds one conversation, named by id, in the Cosend Inbox to hand it over; reason is an optional note for them. They get a hand-over prompt: when they say yes, or do not answer within 60 seconds, the chat passes to the person this app acts for, and messages can be sent in it; when they say no, it stays theirs. This is the way into a chat someone else holds: every hand-over starts with asking its holder. A chat nobody holds, or one the person this app acts for already holds, is refused, as there is nothing to ask for and a message can be sent there as it is. Asking again while a request waits returns that request. Returns the request: its state (pending until answered), who holds the chat (held_by) and when it passes without an answer (expires_at). Whether it has passed shows in the conversation’s lock (held_by, can_i_send). The request stays inside Cosend, out of the customer’s view.

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": {
      "id": "<id>"
    },
    "name": "ask_for_conversation"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	The conversation to ask for.
`reason`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4.3/5.0

Behavior4/5

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

The description goes well beyond the annotations, which only flag it as non-read-only, destructive, idempotent and closed-world. It discloses the hand-over prompt, the 60-second auto-pass, the yes/no branches, refusal conditions, and that the request stays inside Cosend and out of the customer's view. Minor gap: nothing explains why destructiveHint is set true for what reads as a reversible request, leaving an agent to guess at side effects.

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?

The action is front-loaded and the state machine is laid out compactly in one paragraph. Some clauses repeat the send-permission point ("messages can be sent in it" and "a message can be sent there as it is"), which slightly inflates an otherwise dense 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?

There is no output schema, and the description compensates by describing the return payload: request state (pending until answered), held_by, and expires_at. It also points to where the outcome surfaces in the conversation's lock. Nothing an agent needs to invoke or interpret this call 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 coverage is 50%, with only `id` documented in the schema, so the description must carry `reason` — and it does, defining it as an optional note for the holder. `id` is characterized as naming the conversation in the Cosend Inbox, reinforcing the schema. The format of `id` is never specified, but the added meaning is otherwise solid.

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 specific verb and resource: ask the holder of one conversation, named by id, in the Cosend Inbox to hand it over. It also carves out a niche against siblings by stating "This is the way into a chat someone else holds," which implicitly separates it from send_message and take_over_conversation. It does not name the adjacent hand-over tool explicitly, so the differentiation is inferential rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the positive case (a chat someone else holds), the exclusion (a chat nobody holds or one already held by the person this app acts for is refused), and the alternative for that case (a message can be sent there as it is). It also covers the repeat-call case: asking again while a request waits returns that request.

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

All Cosend 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?