Skip to main content
Glama

Purchase a 30-day private jq pass

purchase_access
Idempotent

Purchase or resume a prepaid access pass for the UUID configured in the MCP client Authorization header. The fixed price is 2 USDC for 30 days of unlimited jq queries and zero application query logs; each renewal is a separate purchase after expiration. Use only when paid access is wanted; use get_quota to inspect active access first. An active pass returns its status without charging again. Discovery and status checks are free. Expired paid UUIDs reject ordinary queries until renewed or explicitly paid per query and never fall back to tracked free access, even after old billing records are deleted. Browser wallet checkout and private MCP settings are available at https://thejqapi.com/access; ordinary MCP clients need no wallet after payment. Requires an x402-capable client with a funded wallet and an explicit spending policy allowing 2 USDC. The initial tool error contains standard x402 v2 PaymentRequired data. Retry with the signed payment in request _meta["x402/payment"], never in arguments. The optional purchase_id resumes an earlier order; keep the same order on retries. The UUID remains a secret bearer credential and must never be included in arguments. Returns active status or a purchase_id, settlement status, transaction receipt, and expires_at when activated. A pending settlement must be checked again without a new payment. Invalid input is 400, missing UUID 401, unavailable purchase 404, conflicting or expired order 409, and disabled/unavailable billing 503. Purchases are live with native USDC on Base mainnet (eip155:8453). The pass preserves 5 MiB document and 15-minute upload limits. Minimal billing/access records and explicitly requested uploads are retained separately. Payments are public onchain; Cloudflare infrastructure policies apply. GET https://thejqapi.com/pricing reports current availability.

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

Input Schema

NameRequiredDescriptionDefault
purchase_idNoOptional purchase_id returned by an earlier purchase attempt. Reuse it to resume that purchase or recover its receipt; omit to create or resume the caller’s open purchase. This is not your UUID bearer credential.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, the description discloses price, duration, no application query logs, renewal rules, no-charge behavior for active passes, x402 payment flow, retry mechanics, error codes, settlement handling, network, and retention constraints. These details are consistent with the annotations: it is a non-read-only, open-world, idempotent, non-destructive purchase operation.

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?

The description is long, but it is front-loaded with the core action, price, and usage guidance before moving into payment and error details. Most sentences carry operational value for a complex x402 purchase flow, though a few infrastructure and policy details could be trimmed.

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?

Given the payment complexity, absence of an output schema, and single optional parameter, the description is highly complete. It explains return fields, error statuses, payment retry behavior, settlement checks, and the credential boundary, which an agent needs to invoke the tool correctly.

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?

Schema coverage is 100% and the purchase_id parameter is already well documented in the schema. The description adds useful retry semantics by saying to keep the same order on retries and explaining that this parameter resumes an earlier order rather than acting as the UUID credential.

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?

The description states a specific verb and resource: purchase or resume a prepaid access pass for the configured UUID. It distinguishes the paid action from free status or discovery checks and from sibling tools such as get_quota.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says to use this only when paid access is wanted and to inspect active access with get_quota first. It also explains behavior for active passes, expired passes, renewals, and retries, giving clear when-to-use guidance and alternatives.

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.

Resources