Skip to main content
Glama

Pricing and payment check

pricing_check

Whether people who reach the pricing page (a website) or the paywall (an app) can pay, for any stack and payment provider. Returns steps: each step from pricing to paid (a site: pricing seen, plan picked, checkout opened, paid, renewal or top-up, from the mapped funnels; an app: paywall seen, trial started, paid, renewed, from App Store Connect and the subscription service), each counted, silent or missing, with untracked first and paidGap when the analytics count far fewer payments than the provider; entry: the entry model the agent read in the code beside sourced benchmarks for this kind of product; own: the founder's own pricing changes and their before and after; walk: the checks to make in the founder's Chrome or the code, never paying or creating an account (steps-tracked, checkout-phones, wallets, local-price, promo-code, billing-page, paid-gated, paywall-exposure, dunning, trial-day0); changes: the changes ranked by evidence, the ones that answer a failed check first, and pick, the one to make; judge: how a change is read (paid per visitor, directional below 9,000 views per variant, with its stop date set now); hardLines. Call again with record (pass or fail with evidence per check), model (the entry model) and counts (what you read in the provider's dashboard or the subscription service). Never changes a price, a plan or a customer. Free.

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": "pricing_check"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNoDefault: app for an App Store app, web otherwise
modelNoThe entry model read in the code: how a new user gets in before paying
countsNoWhat you read where only you can: the provider's dashboard, the subscription service
recordNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) already cover the safety profile, and the description adds substantial context on top: it names the data sources (mapped funnels, App Store Connect, the subscription service, the provider's dashboard), states 'Never changes a price, a plan or a customer', notes the walk happens in the founder's Chrome or the code 'never paying or creating an account', and discloses the judgment rule (directional below 9,000 views per variant, stop date set now). No return-format or rate/permission caveats, so not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and every clause carries information, but the body is one dense run-on paragraph with colon-chained lists that are hard to parse on first read. Length is justified by the tool's scope, yet the phrasing ('Whether people who reach ... can pay, for any stack and payment provider', 'judge: how a change is read') could be tightened considerably without losing content.

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 four-parameter, nested-schema tool with no output schema, the description does the necessary work of describing what comes back: the per-step counts with untracked first and paidGap, the entry model with benchmarks, the founder's own before/after, the ranked changes with a pick, the judging rule, and hardLines. What is missing is routing against sibling diagnostics, which matters given how many overlap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 75% schema coverage the schema already carries much of the load, but the description earns credit beyond it: it explains that 'record' is pass or fail with evidence per check, that 'counts' is what you read in the provider's dashboard or subscription service, and it enumerates the ten checks that populate record.check (steps-tracked, checkout-phones, wallets, local-price, promo-code, billing-page, paid-gated, paywall-exposure, dunning, trial-day0). 'kind' is left to its schema default, which is the only real gap.

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 opening sentence states a specific question the tool answers: whether people reaching the pricing page (web) or paywall (app) can pay, across any stack and provider, and the rest enumerates the concrete outputs (steps, entry, own, walk, changes, judge). That is far more specific than a restated name. It never names a sibling (e.g. funnel_check, tracking_check, landing_check) to differentiate, which keeps it from 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?

There is real usage signal in 'Call again with record (pass or fail with evidence per check), model ... and counts', which tells the agent this is a two-phase flow (inspect first, then report findings). However, nothing says when to use this versus the adjacent diagnostics like funnel_check or tracking_check, and there are no stated prerequisites beyond what the walk checks imply.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.