OsmO AI Receptionist

Place a Call

place_call

Destructive

Places phone calls on the user's behalf: OsmO's AI assistant calls and speaks the reason given. Calls one number (contactId or phoneNumber) or 1 to 5 numbers (recipients), now or at a later time (scheduledAt). OsmO calls the user's saved contacts, people who called them in the last 30 days, and listed businesses. Without confirmed:true nothing is dialled: it returns confirmation_required listing every number, the reason and the time. confirmed:true means the user has approved that preview; the calls are then placed or booked and a callId is returned for each. Not for emergency services or text messages. Calls it can make include: booking, rescheduling or cancelling an appointment or a table; asking a shop, clinic or restaurant about opening hours, prices, stock or an order; getting through a company's phone menu to customer service; and passing a message to one of the user's contacts. Once a call ends, its outcome and a summary of what was said are recorded.

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": {
      "reason": "<reason>"
    },
    "name": "place_call"
  }
}

Input Schema

Name	Required	Description
`time`	No	A preferred time to mention on the call, as speech, e.g. "tomorrow at four PM".
`reason`	Yes	What the call is for; the assistant says it in its opening line, e.g. "book a table for four at eight tonight". At most 300 characters. Longer text is refused, never cut.
`context`	No	Details the assistant uses during the call but does not read out: names, booking or order numbers, amounts, questions to ask. At most 700 characters. Longer text is refused, never cut.
`confirmed`	No	true means the user has approved the confirmation_required preview returned by an earlier call with the same arguments, and carries it out. Without it nothing changes and that preview is returned.
`contactId`	No	One person to call now: a contactId from find_contact.
`recipients`	No	To call 1 to 5 numbers in one go: each a contactId or a phoneNumber.
`contactName`	No	Who is being called. Shown in the call log.
`phoneNumber`	No	One number to call now, in full international form, e.g. +919876543210.
`scheduledAt`	No	To place the calls LATER: ISO 8601 with the offset, at least 2 minutes ahead, e.g. "2026-11-13T09:30:00+05:30". Leave out to call now.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 15, 2026

addedInput schema / properties / context

Added value: +{
+  "description": "Details the assistant uses during the call but does not read out: names, booking or order numbers, amounts, questions to ask. At most 700 characters. Longer text is refused, never cut.",
+  "type": "string"
+}

changedInput schema / properties / reason / description

Previous value: -"What the call is about, in the user's own words; the assistant says it."New value: +"What the call is for; the assistant says it in its opening line, e.g. \"book a table for four at eight tonight\". At most 300 characters. Longer text is refused, never cut."

First observedNov 15, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, openWorldHint=true and readOnlyHint=false, so the write/real-world profile is known; the description nonetheless adds real value by disclosing the two-step confirmation contract (nothing dialled without confirmed:true, a preview listing numbers/reason/time is returned) and the post-call recording of outcome and summary. It omits cost, rate limits, and what happens if a call fails or is declined, which for a destructive open-world tool would be worth stating.

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?

Front-loaded with purpose, then scope, then the confirmation contract, then allowed call types and the result — a logical order with no filler sentences. It is dense and the confirmation behavior is explained twice (once in the "Without confirmed:true" sentence, again in the confirmed:true sentence), costing a little tightness.

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 nine-parameter, destructive, open-world tool with no output schema, the description covers everything an agent needs: the callable-number universe, recipient limits, scheduling constraints, the confirmation handshake, and the return values (confirmation_required preview, one callId per call, recorded outcome and summary).

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

Parameters3/5

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

Schema coverage is 100%, so the schema already documents all nine parameters including limits (300/700 chars), ISO 8601 with offset, and the +2 minute minimum. The description's contribution is the either/or semantics (single contactId/phoneNumber versus a recipients array of 1-5, now versus scheduledAt), which is genuinely helpful but mostly restates what the schema encodes.

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?

Opens with a specific verb and resource ("Places phone calls on the user's behalf") and immediately scopes it: the AI assistant speaks the supplied reason, dials one number or 1-5, now or scheduled. The enumerated call categories (booking, hours/stock enquiries, phone-menu navigation, message passing) make it unmistakable versus siblings like get_call or list_calls.

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?

Explicit when-not guidance is present: "Not for emergency services or text messages," plus the prerequisite that the user must have approved the confirmation_required preview before confirmed:true. It does not route to any sibling by name (e.g. cancel_scheduled_call for undoing a booked call), so alternatives are left to inference, keeping it short of a 5.

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

All OsmO AI Receptionist 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.