Skip to main content
Glama
Sign In
Payware MCP Server

Payware MCP Server

Official
by payware
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

payware_products_create_airing

Adds scheduled airing rules to a product placement, defining repeat frequency, time windows, and date ranges while flagging overlap warnings.

Instructions

[Merchant] Add an airing rule to a placement: up to 100 rules per placement. Example: "daily 08:00-08:30 and 15:40-16:10" is one DAILY rule with two windows. Check warnings in the response: AIRING_OVERLAP means another soundbite placement of the same product airs at the same time in an overlapping region, and a tap then is attributed to neither.

Endpoint: POST /products/{productId}/placements/{placementId}/airings (PRM plan)

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": {
      "productId": "<productId>",
      "placementId": "<placementId>",
      "frequency": "<frequency>",
      "startDate": "<startDate>",
      "windows": "<windows>"
    },
    "name": "payware_products_create_airing"
  }
}

Input Schema

NameRequiredDescriptionDefault
endDateNoLast day, YYYY-MM-DD, at most 366 days after startDate. Omit for open-ended
windowsYesTime windows on each day it airs, local to the time zone: 1 to 24, each up to 6 hours
timeZoneNoIANA time zone, e.g. Europe/Sofia. Default: the product's
frequencyYesHow the rule repeats
monthDaysNoMONTHLY by date: days of the month. A day a month lacks is skipped
monthWeekNoMONTHLY by weekday: which week, -1 for the last. Use with monthWeekday
productIdYesThe product's ID: pr + 8 letters or digits, e.g. pr7e4rCToG
startDateYesFirst day, YYYY-MM-DD, in the rule's time zone
daysOfWeekNoWEEKLY: the days it airs on
useSandboxNoUse the sandbox (the default) rather than production
placementIdYesThe placement's ID: pl + 8 letters or digits, e.g. pl7e4rCToG
repeatEveryNoEvery N days, weeks or months. Default 1
monthWeekdayNoMONTHLY by weekday: the weekday
excludedDatesNoDays it does not air, YYYY-MM-DD
expectedAudienceNoExpected audience per airing, for your own planning

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.2.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare a non-read-only, non-idempotent, non-destructive open-world mutation, so the safety profile is covered. The description adds genuine behavioral context beyond that: the per-placement rule limit and the AIRING_OVERLAP warning, including the business consequence that an overlapping tap is attributed to neither placement. Minor gaps remain around permissions/plan gating beyond the '(PRM plan)' tag and whether duplicate rules are rejected.

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?

Content is front-loaded: purpose, limit, example, then the warning semantics, then the endpoint. Every sentence carries information, though the trailing endpoint/plan boilerplate is the least valuable element and the bracketed '[Merchant]' tag adds little to an agent's decision.

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 15-parameter mutation with no output schema, the description supplies what is otherwise missing: scope limits, a construction example for the trickiest input combination, and the meaning of the response's warnings field. That covers both how to call it and how to interpret the result, which is the key gap an absent output schema would otherwise leave.

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% and each parameter (windows, frequency, monthDays, repeatEvery, timeZone) is documented inline, so the schema does the heavy lifting and the baseline is 3. The worked example does clarify the non-obvious relationship between frequency and the windows array, but the description adds no new meaning for the other 13 parameters such as monthWeek/monthWeekday pairing or expectedAudience.

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 uses a specific verb and resource: 'Add an airing rule to a placement', reinforced by the concrete endpoint POST /products/{productId}/placements/{placementId}/airings. An agent can immediately tell this creates a recurring airing rule rather than reading or replacing one, though it never names the sibling tools (update_airing, replace_airings, list_airings) that are the nearest alternatives.

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?

It gives clear context for use: a hard cap of 100 rules per placement and a worked example showing that one DAILY rule can carry multiple windows ('daily 08:00-08:30 and 15:40-16:10'). It stops short of explicit when-to-use/when-not guidance, e.g. whether to call this versus update_airing or replace_airings when a rule already exists.

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

Deploy Server

Other Tools