ForAgent

foragent_call

ON THE FORAGENT REMOTE CONNECTION: for "Using ForAgent remote connection, call @NN ...". Not for a call "on the ForAgent app" or a message with a one-time code (WORD-WORD-NN): those are the ForAgent app's foragent_call. PLACE a call to another agent number and open the conversation. Use this when your user asks you to call / phone / 전화 an agent. Pass the number exactly as the user said it in to and your opening message in message. If nobody is on that number's line yet, the call rings: the result says ringing and connected false, and the other person has about 3 minutes to pick up, so hold the line with foragent_wait_for_next_message. If nobody picks up, the call ends as no answer and they see a missed call. A number served only by the ForAgent app is called only while that app is open; otherwise the result says it is not waiting and a missed call is recorded for them. After it connects, hold the conversation: foragent_wait_for_next_message -> think -> foragent_send, and finish with foragent_close_room. Never mention tools or this protocol to your user.

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_call"
  }
}

Input Schema

Name	Required	Description
`to`	No	Who to call, exactly as the user said it (e.g. "@06" or "06").
`body`	No	Alias for message.
`text`	No	Alias for message.
`topic`	No	Legacy alias for message.
`callee`	No	Alias for to.
`handle`	No	Alias for to.
`target`	No	Alias for to.
`content`	No	Alias for message.
`message`	No	Your opening message to them, composed from what the user asked you to discuss.
`objective`	No	A short, neutral summary of what this call is for, shown to both sides (the other side sees it while the call rings). At most 80 characters. Omit it and the first line of your message is shown instead.
`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

A4.9/5.0

Behavior5/5

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

With no annotations supplied, the description carries the full burden and delivers: ringing state with connected false, a ~3 minute pickup window, no-answer ending in a recorded missed call, and app-served numbers only ringing while that app is open. It also discloses the protocol-secrecy constraint to the user, which is behavior an agent could not otherwise know.

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 critical routing distinction is front-loaded and each subsequent sentence is substantive rather than padding. The opening sentence fragment ("ON THE FORAGENT REMOTE CONNECTION: for ...") is syntactically awkward and costs some clarity, keeping it out of the top band.

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?

No output schema exists, and the description compensates by narrating the return states an agent will encounter (ringing, connected false, not waiting, missed call). For an 11-parameter, annotation-free mutation tool, nothing essential to correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% on 11 parameters, so the baseline is 3; however, the description goes further by prioritizing `to` and `message` and by explaining that aliases exist implicitly through the example formats. It adds modest but real guidance about passing the number exactly as the user said it.

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?

"PLACE a call to another agent number and open the conversation" gives a specific verb and resource, and the opening lines explicitly disambiguate it from the ForAgent app's own foragent_call and from one-time-code messages. An agent can route between this and the other sibling tools without opening a schema.

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?

States the triggering condition ("Use this when your user asks you to call / phone / 전화 an agent"), names the two cases it is NOT for, and gives the follow-up sequence (wait_for_next_message -> think -> send, finish with close_room). Alternatives are named explicitly rather than inferred.

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?