Free service catalog (no payment): every paid endpoint with its exact price in USDC, the settlement network, USDC asset, payTo address, facilitator and the step-by-step x402 how-to-pay flow, plus the free allowance this caller has left. Call this first to learn what webcap sells and what it costs.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Input schema / properties / payerRemoved value: -{
- "description": "Optional 0x-prefixed 20-byte EVM address. When given, the result also lists which free trials that wallet has claimed and which it can still claim. Omit for the plain catalog.",
- "pattern": "^0x[0-9a-fA-F]{40}$",
- "type": "string"
-}Input schema / properties / payerAdded value: +{
+ "description": "Optional 0x-prefixed 20-byte EVM address. When given, the result also lists which free trials that wallet has claimed and which it can still claim. Omit for the plain catalog.",
+ "pattern": "^0x[0-9a-fA-F]{40}$",
+ "type": "string"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the tool is free (no payment), returns exact pricing, and reports the caller's remaining free allowance. It does not mention auth requirements or rate limits, but for a public read-only catalog those gaps are minor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the free-of-charge nature and a compact enumeration of what is returned. Every element earns its place and the closing directive is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must describe the return content; it does so by listing the specific fields (prices, network, asset, payTo, facilitator, x402 flow, allowance). This is complete enough for an agent to know exactly what to expect from a zero-parameter catalog call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there are no parameter semantics to explain. Per the baseline rule for 0 params, a 4 is appropriate; the description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource (service catalog) and enumerates its contents: paid endpoints, USDC prices, settlement network, payTo address, facilitator, x402 flow, and caller's free allowance. This clearly distinguishes it from sibling action tools like webcap_analyze or webcap_capture, which perform operations rather than catalog discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly directs the agent to 'Call this first' to learn what webcap sells and what it costs. That is a clear when-to-use instruction, and for a discovery/catalog tool no alternative or exclusion is necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.