Skip to main content
Glama
Sign In

CallMCP — Phone Call MCP Server

by ai.callmcp
OverviewDiscussionsAdmin

Schedule Activity Report Emails

agency_report_configure
DestructiveIdempotent

Sets the weekly or monthly activity report email schedule for an installation and replaces the previous recipient list. Requires the client owner; recipients must be verified members of the client's business. The first report is sent by the scheduled job, not by this call.

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": {
      "partnerId": "<partnerId>",
      "installationId": "<installationId>",
      "expectedRevision": "<expectedRevision>",
      "recipients": "<recipients>",
      "cadence": "<cadence>"
    },
    "name": "agency_report_configure"
  }
}

Input Schema

NameRequiredDescriptionDefault
cadenceYesweekly or monthly.
partnerIdYesThe agency (partner) workspace ID.
recipientsYesUser IDs (1-20) of verified business members who should receive the report.
installationIdYesThe agency package installation to act on.
expectedRevisionYesThe installation revision you last read. The call is rejected if the installation has changed since.

Output Schema

NameRequiredDescriptionDefault
errorNoPresent when success is false
receiptNo
successYesWhether the tool completed successfully

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior5/5

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

Beyond the annotations, it discloses that the call replaces the existing recipient list (explaining the destructiveHint), that it requires client-owner authorization, that recipients are validated as verified business members, and that no report is sent by this call itself. These are exactly the behavioral facts an agent needs before invoking a destructive scheduling mutation.

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?

Three tight sentences with no filler. The core action and its replacement semantics come first, followed by prerequisites and then the timing caveat.

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

Completeness4/5

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

With annotations, a full schema, and an output schema, the description covers the important gaps: authorization, destructive replacement, recipient validation, and send timing. It could say slightly more about the effect of the expectedRevision guard on call outcomes, but nothing essential is missing.

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 description coverage is 100%, so all five parameters are already documented, including the enum for cadence and the revision guard. The description reinforces the recipients constraint but adds little semantic detail beyond what the schema already states, so the baseline of 3 applies.

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 states a specific verb and resource: it 'sets the weekly or monthly activity report email schedule for an installation' and 'replaces the previous recipient list.' That is clearly distinct from a report-generation tool. It does not explicitly name a sibling (e.g. agency_report_generate) as the alternative, so it stops short of a 5.

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

Usage Guidelines3/5

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

It gives useful preconditions: the client owner is required and recipients must be verified members of the client's business. However, it never states when an agent should choose this over related tools or when not to call it, leaving routing to inference.

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

All CallMCP — Phone Call MCP Server 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