Owner-test wallet only while the public pilot is disabled; bounded verified-payer eligibility exists only while its durable window is armed. Product search costs 0.022 USDC on Base via official x402; explicit idempotency is required for non-owner orders. Other tools are sandbox.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
Changes observed during successful MCP inspections.
Input schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / request / additionalPropertiesPrevious value: -trueNew value: +falseInput schema / properties / request / propertiesAdded value: +{
+ "idempotency_key": {
+ "pattern": "^[A-Za-z0-9._:-]{1,128}$",
+ "type": "string"
+ },
+ "page": {
+ "type": "integer"
+ },
+ "page_size": {
+ "maximum": 10,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "q": {
+ "maxLength": 200,
+ "minLength": 1,
+ "type": "string"
+ }
+}Input schema / properties / request / requiredAdded value: +[
+ "q"
+]Input schema / properties / request / titleRemoved value: -"Request"Input schema / titleRemoved value: -"invoke_paidArguments"Input schema / titlePrevious value: -"invokeArguments"New value: +"invoke_paidArguments"Output schema / (root)Previous value: -{
- "additionalProperties": true,
- "title": "invokeDictOutput",
- "type": "object"
-}New value: +nullDoes the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations it discloses concrete behavior: a 0.022 USDC x402 charge on Base, that explicit idempotency is required for non-owner orders, and that access depends on wallet/pilot state. This is meaningful context, though it never explains what the destructiveHint=true annotation actually means for a search operation.
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?
Three dense, jargon-heavy sentences lead with access gating and payment mechanics rather than the tool's actual function. The core purpose appears mid-sentence and the wording ('durable window is armed', 'bounded verified-payer eligibility') obscures more than it clarifies.
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?
For a paid, mutating, nested-parameter tool with no output schema and zero parameter documentation, the description omits return shape, pagination behavior, and most parameter meanings. The agent cannot confidently construct a call from this definition alone.
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?
Schema description coverage is 0% and the nested request object contains four undocumented fields (q, page, page_size, idempotency_key). The description only touches idempotency_key, leaving the primary search term and pagination parameters entirely unexplained.
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 phrase 'Product search' names a resource and verb, but it is buried in the middle of access-gating and payment boilerplate. It does not clearly separate this from sibling invoke_product_detail_v0 or discover_product_keyword_search_v0, so the agent must infer the distinction.
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?
The description gives eligibility conditions (owner-test wallet, verified-payer window, pilot disabled) but never states when to choose this tool over the sibling search/detail tools. The trailing 'Other tools are sandbox' is a weak differentiation hint rather than actionable routing guidance.
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.