CallMCP — Phone Call MCP Server

Save Agency Offer Draft

agency_offer_save

Creates a new offer draft, or replaces an existing draft when offerId and its current revision are given. Requires an agency owner or admin. Saving changes only the draft; clients see nothing until it is published.

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>",
      "draft": "<draft>"
    },
    "name": "agency_offer_save"
  }
}

Input Schema

Name	Required	Description
`draft`	Yes	The offer: name, industry, commercial mode, retail price and scope, 1-3 packages, supported claims, support policy and the branding-limitations acknowledgement.
`offerId`	No	Existing offer to update. Without it, a new draft is created.
`partnerId`	Yes	The agency (partner) workspace ID.
`expectedRevision`	No	Current draft revision; required when offerId is given.

Output Schema

Name	Required	Description
`error`	No	Present when success is false
`receipt`	No
`success`	Yes	Whether the tool completed successfully

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations only declare a non-read-only, non-destructive, non-idempotent write. The description adds real context beyond them: the owner/admin role requirement, the fact that changes stay invisible to clients until published, and the revision requirement that implies stale-revision conflicts. It stops short of describing what happens on a revision mismatch or the response shape.

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 sentences, each carrying distinct information: the operation modes, the permission prerequisite, and the draft/publish boundary. The create-or-replace condition is front-loaded, with no filler.

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?

An output schema exists, so return values need no explanation, and the deeply nested draft object is fully specified in the schema. For a mutation with concurrency control, the only meaningful gap is the failure behavior on a stale expectedRevision, which an agent might want stated.

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 the baseline is 3. The description reinforces the offerId/expectedRevision pairing, but that dependency is already documented in the schema property descriptions, so it adds little new meaning; the nested draft fields are left entirely to the schema.

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?

States a specific verb+resource (creates/replaces an offer draft) and spells out the two distinct modes: create when offerId is absent, replace when offerId plus its current revision is supplied. The closing sentence distinguishes it from the publish sibling by noting clients see nothing until publication.

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 the selection rule between create and replace (presence of offerId and expectedRevision) and the authorization precondition of agency owner or admin. It does not explicitly name agency_offer_publish as the next step for making the offer live, leaving that inference to the reader.

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 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.