ToolSnap MCP

Pricing and payment options

pricing

Read-only

Check exact tool costs, first-call-free eligibility, and pay-per-call or prepaid options before using a paid tool.

Instructions

Free, read-only, no network, no arguments; calling it charges nothing. Call it before a paid tool to see its exact cost and whether first_call_free applies, or to choose pay-per-call vs prepaid. Returns a JSON menu: endpoint and docs URLs; payment with x402 USDC on Base, minimum deposit, prepaid discount and SpendAuthorization fields; tools[] with name and tier free|paid, plus price_usdc, prepaid_price_usdc, first_call_free and a value note for paid ones. Flat prices are exact; fal.ai media tools show a default-args quote. For what a tool does and its schema use tool_catalog; this one is only about cost.

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

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Jun 25, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses that invocation is free ('calling it charges nothing'), that prices can be exact or a default-args quote depending on the tool (fal.ai media), and what payment mechanics exist (x402 USDC on Base, minimum deposit, prepaid discount, SpendAuthorization). These are non-obvious traits an agent needs before relying on the numbers.

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 cost/read-only constraint, then routing guidance, then return shape, then the boundary against tool_catalog — a logical order. The return-value enumeration is dense and long, but it substitutes for the missing output schema, so most of it earns its place.

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?

With no output schema, the description carries the burden of describing return values and does so concretely (menu fields, tools[] with tier, price_usdc, first_call_free, value note). It also notes the precision caveat for quoted prices, so an agent knows how much to trust the numbers.

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?

Zero parameters, so the baseline is 4; the description reinforces this with 'no arguments,' matching the empty schema. Nothing further is needed or claimed.

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?

States a specific resource (pricing/payment options), its cost profile ('Free, read-only, no network, no arguments'), and precisely what it returns (a JSON menu of tiers and prices). It explicitly distinguishes itself from the sibling tool_catalog by scope: 'this one is only about cost.'

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?

Gives explicit when-to-use: 'Call it before a paid tool to see its exact cost and whether first_call_free applies, or to choose pay-per-call vs prepaid.' It also routes the agent away to the correct alternative for a different need: use tool_catalog for descriptions and schemas.

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

Deploy Server