Skip to main content
Glama
Sign In
Payware MCP Server

Payware MCP Server

Official
by payware
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

payware_campaigns_get_campaign_stats

Read-onlyIdempotent

Retrieve campaign performance statistics for a date range, including offer resolutions, soundbite recognitions, started and confirmed transactions, and confirmed amounts by currency.

Instructions

[Merchant] A campaign's results over [from, to): offers shown when a bank resolved one of its placement IDs (resolutions), offers shown after a recognised soundbite tap (recognitions), payments started (transactions) and confirmed, and confirmed amounts by currency.

Endpoint: GET /campaigns/{campaignId}/stats (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": {
      "campaignId": "<campaignId>"
    },
    "name": "payware_campaigns_get_campaign_stats"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoEnd of the period, exclusive, in the same forms. Default: now. Any length: impressions are kept for good
fromNoStart of the period: a date (YYYY-MM-DD, the start of that day in UTC) or an ISO-8601 instant with an offset, e.g. 2026-10-19T00:00:00+03:00. Default: 30 days before to
campaignIdYesThe campaign's ID: cp + 8 letters or digits, e.g. cp7e4rCToG
useSandboxNoUse the sandbox (the default) rather than production

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.2.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and open-world access, so the safety profile is covered. The description adds useful domain context (what resolutions, recognitions, and transactions mean, plus the PRM plan gate) but does not cover pagination, latency, or how retention interacts with very old 'from' values.

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 the tool's purpose and the four metrics, followed by a compact endpoint line. The metric enumeration is dense but each clause carries meaning; the only slight waste is the '[Merchant]' tag whose value is inferable from the PRM plan note.

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?

For a read-only stats tool with full schema coverage and annotations, the description covers what is measured and the plan requirement, which is enough to call it correctly. Absent an output schema, it could say more about the shape of the returned stats object, but the metric list largely substitutes for that.

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 four parameters including date formats, defaults, campaignId pattern, and useSandbox. The description reinforces the exclusive-end [from, to) semantics, which is a small addition, but adds no syntax or constraint detail beyond the schema. Baseline 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 (campaign stats over [from, to)) and enumerates the four metric families returned: resolutions, recognitions, transactions, and confirmed amounts by currency. It also names the exact endpoint. It does not explicitly distinguish itself from the sibling placement-stats tool, though the metric vocabulary hints at the difference.

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?

The '[Merchant]' prefix and 'PRM plan' note imply the audience and plan requirement, and the [from, to) framing implies a period query. But there is no explicit when-to-use vs when-not, and no guidance on choosing this over payware_products_get_placement_stats or payware_operations_get_transaction_history.

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