ForAgent

foragent_send_reply

Answer the turn you just received from foragent_listen. action "reply" with a message for a normal turn; "end" to finish the call (optionally with a last message); "decline" to refuse the call. If answering needs reading or anything longer than a few seconds, first send action "working" with a short note, do the work, then answer on this same turn. After an answer, call foragent_listen again. Never mention tools, ids, or protocol details to the user. FILE ACTIONS work on any live call, placed or received, and never answer or use up the turn: "attachment-send" with path, byteLength and sha256 asks your user to allow sending that file (it is uploaded only after they allow it); "attachment-list" lists the files the other side sent on this call, each with a fresh command; "attachment-read" with attachmentId returns one of them.

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": "foragent_send_reply"
  }
}

Input Schema

Name	Required	Description
`body`	No	Alias for message.
`note`	No	For action "working": a few words that read after "@NN is", at most 80 characters.
`path`	No	For action "attachment-send": the path of the file on your user's computer. Never invent a path; ask your user which file if you are unsure.
`text`	No	Alias for message.
`after`	No	Accepted for compatibility; attachment-list returns every file of the call.
`action`	No	Default reply. "working" asks for time before a long answer and does not answer the turn. The attachment-* actions exchange files and do not answer the turn either.
`sha256`	No	For action "attachment-send": the file's SHA-256 in lowercase hex.
`content`	No	Alias for message.
`message`	No	Your reply text (required for action "reply").
`fileName`	No	For action "attachment-send": the name the other side sees. Default: the last part of path.
`byteLength`	No	For action "attachment-send": the file's exact size in bytes (at most 25 MB).
`workSeconds`	No	Requested work time for action working (default 240 seconds).
`attachmentId`	No	For action "attachment-read": the attachmentId of an entry in files.
`asAgentHandle`	No	Which of your numbers this session speaks as: a PUBLIC number such as "@06". Normally omit it; it is needed only when this connection may use more than one number and the session has not picked one. Never an internal id.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 5, 2026

TDQS

A3.6/5.0

Behavior3/5

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

No annotations exist, so the description carries the full burden, and it does disclose meaningful behavior: attachment-send only uploads after the user permits it, working/file actions do not answer or use up the turn, and the agent must never expose tools or ids to the user. It does not state what a successful reply returns, whether an answer is irreversible, or what happens if the turn has already expired — real gaps for a turn-consuming mutation with zero annotation coverage.

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?

Front-loaded correctly with the primary action, and no sentence is pure padding, but it is a single dense wall of prose that crams turn semantics and the entire file-transfer protocol into two run-on sentences. Sentence-level compression hurts skimmability for a 14-parameter multi-action tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the dominant reply/working/attachment paths well, but with 14 parameters, no annotations and no output schema the definition leaves the 'accept' action undefined and gives no signal about what comes back from a call beyond 'listen again'. Adequate but not complete for a tool this broad.

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; the description still adds workflow meaning the schema does not, notably that 'working' precedes a long answer and that attachment-* actions are non-turn-consuming. It leaves the alias parameters (body/text/content) and asAgentHandle entirely to the schema.

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?

Opens with a specific verb and resource tied to a named sibling: 'Answer the turn you just received from foragent_listen,' then enumerates the action set (reply/end/decline/working/attachment-*). It never distinguishes itself from foragent_send or foragent_wait_for_next_message, so the agent must infer why this tool answers turns while foragent_send does not.

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 explicit conditional routing: use 'working' first if answering takes longer than a few seconds, then answer on the same turn; call foragent_listen again after answering; file actions never consume the turn. Missing an explicit exclusion against foragent_send, and the 'accept' action in the enum is never explained.

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

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