Skip to main content
Glama
Sign In
Payware MCP Server

Payware MCP Server

Official
by payware
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

payware_logs_query

Read-onlyIdempotent

Retrieve and filter payment application logs by time, level, logger, or search text to debug and monitor your integration; returns paginated JSON entries.

Instructions

[Merchant] Query application logs with filters. Premium plan required. Returns paginated JSON log entries for debugging and monitoring your integration.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "payware_logs_query"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoEnd timestamp in ISO 8601 format (e.g., '2024-01-15T23:59:59Z'). Defaults to now.
fromNoStart timestamp in ISO 8601 format (e.g., '2024-01-15T00:00:00Z'). Defaults to 24 hours ago.
levelNoFilter by log level, an exact match: WARN returns WARN lines only, not ERROR as well (LogAccessService compares the level for equality).
limitNoMaximum records to return (default 1000, max 10000).
cursorNoPagination cursor from previous response for fetching next page.
loggerNoFilter by logger name (partial match). E.g., 'TransactionController' to see transaction-related logs.
searchNoSearch text in log messages. Case-insensitive partial match.
partnerIdNoPartner ID from payware dashboard. Uses PAYWARE_PARTNER_ID env var as default.partner_12345
privateKeyNoRSA private key for authentication. Uses environment-specific private key as default.
useSandboxNoRead the sandbox logs (default) or production's

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.2.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and open-world behavior, so the description's added details are the real contribution: the paid-tier access gate, that results are paginated JSON, and that both sandbox and production logs are reachable (via useSandbox). That is meaningful pre-call context beyond the structured hints; only rate limits or log retention are unmentioned.

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 short sentences, front-loaded with what the tool does, followed by the access constraint and the return shape. Nothing is repeated from the schema and no sentence is 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?

For a 10-parameter, zero-required read tool with full schema coverage and no output schema, the description covers purpose, access gating, and return format adequately, so no output schema is needed. The gap is that the sensitive auth parameters (privateKey, partnerId) and sandbox-vs-production safety are not flagged in prose, though the schema documents them.

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%, and each parameter carries a substantive description with defaults and even an enum equality caveat, so the schema does the heavy lifting. The description adds no parameter-level semantics of its own beyond 'with filters', which is baseline-appropriate for this coverage level.

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 gives a specific verb and resource ('Query application logs with filters'), which is clearly distinct from siblings like payware_logs_status or payware_logs_download_url. It does not explicitly differentiate itself from those siblings, but the phrasing 'for debugging and monitoring' narrows the intent enough to be actionable.

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 supplies one genuine prerequisite ('Premium plan required') and a usage context ('debugging and monitoring your integration'), which is more than most. However, it never states when to prefer the sibling download-URL or status tools, nor any exclusion criteria, so routing between log-related tools is left to inference.

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