ManyLives

Inspect a paid endpoint before paying

inspect_before_paying

Read-only

Inspect any pay-per-call (HTTP 402) endpoint before you pay: decodes its payment terms (version, network, asset, price in dollars, payee), checks the listing metadata, lists problems that make agents fail, and gives a safety verdict: trap-level prices, payment in an unrecognised token, a payee on the sanctions list, or a domain registered in the last 30 days. Plus the seller's track record on the Base network: payments and distinct payer wallets to the payee in the last ~5.5 hours, and our longer samples where we have them. US$0.005 per call; 3 free calls a day.

Input Schema

Name	Required	Description	Default
`url`	Yes	The paid endpoint's https:// URL.
`method`	No	How the endpoint is called (default GET).

Output Schema

Name	Required	Description	Default
`url`	No
`paid`	No
`trial`	No
`offers`	No
`safety`	No
`status`	No
`message`	No
`version`	No
`problems`	No
`pay_per_call`	No
`seller_record`	No
`discovery_metadata`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 11, 2026
- addedOutput schema / properties / seller_record
```
Added value: +{}
```

Changed2 schema fields changedOct 11, 2026

addedInput schema / properties / method / description

Added value: +"How the endpoint is called (default GET)."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "discovery_metadata": {},
+    "message": {},
+    "offers": {},
+    "paid": {},
+    "pay_per_call": {},
+    "problems": {},
+    "safety": {},
+    "status": {},
+    "trial": {},
+    "url": {},
+    "version": {}
+  },
+  "type": "object"
+}

AddedOct 11, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare readOnly/openWorld/non-destructive, but the description adds substantial context beyond them: concrete cost (US$0.005 per call), a free-tier rate limit (3 free calls/day), and the specific verdict triggers (trap prices, unrecognized token, sanctions list, domain age) plus the Base-network track-record scope. This is rich disclosure the agent cannot get from structured fields.

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?

Purpose and payout/rate-limit facts are front-loaded, and most clauses are load-bearing (verdict triggers, cost, free tier). It is dense but slightly overlong with the stacked list of verdict conditions, though nothing is truly redundant.

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 an output schema documenting return values and annotations covering the safety profile, the description only needs to convey scope, cost, and check coverage, which it does fully. Nothing an agent needs to call this correctly is missing.

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% for both the required url and the optional method enum, so the schema already carries parameter meaning. The description adds no syntax or format detail beyond it, making the baseline 3 appropriate.

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 precise verb and resource (inspect a pay-per-call HTTP 402 endpoint) and enumerates exactly what it decodes and checks: payment terms, listing metadata, failure risks, and a safety verdict. This is clearly distinguishable from siblings like find_paid_tools or list_services.

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

Usage Guidelines4/5

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

The 'before you pay' framing gives clear timing context for when to invoke it, and the enumerated checks imply its role as a pre-payment gate. However, it never names an alternative tool or states when-not to use it (e.g., vs. a plain listing lookup), so it stops short of explicit routing.

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

All ManyLives tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?