Skip to main content
Glama
pangolinfo

Amazon All-in-One Scrape MCP

Official

wipo_search

Search design patents across 12 global sources. Enable litigation mode to check US patent lawsuits for each result.

Instructions

[Design Patent TRO risk control · WIPO global design / IP search] Query the WIPO design database across 12 sources (USPTO US designs, CNID China, HAGUE international registrations, …), with one-click chaining to US design-patent TRO (temporary restraining order) / litigation risk control. Use when: user says "check trademark" / "design patent search" / "any IP risk for new product" / "X company's patent portfolio" / "WIPO search" / "USPTO query" / "what is registration DM/XXX"; pre-launch IP clearance during scouting/GTM SOPs; competitor IP-portfolio research. Don't use: for keyword ranks / product reviews / product detail (this is an IP database, not a commerce database); for US text-trademark search (this DB focuses on design patents — text trademark coverage is limited). Returns: data.data.{ total, hits[{ IRN, HOL[], DETAIL_DATA.structured.{indication_of_products, statement_of_novelty, ...}, IMG[], IMG_DATA[{filename,url}], DC, RD, STATUS, LCS[], DS[], PROD[], SOURCE, DETAIL_URL }] }. With enableLitigation=true each matched patent additionally carries litigationStatus(success/skipped/failed) + caseTotal + cases[{ caseId, docketNumber, caseName, court, status, dateFiled, parties[], patentNumbers[], entries[] }] (backed by US PACER litigation data — one call returns patents + lawsuits). Pair with: ↑ source required; hol=holder name / prod=product name / irn=international registration / lcs=design classification; enableLitigation=true chains US litigation lookup (IP-risk loop, no separate tool needed); ↓ DETAIL_URL lets the user jump to WIPO's official page to verify. Cost: ~2 points/call, ~5s; with enableLitigation=true add +12 points only when a patent is found (free if none). ⚠️ Perf contract: CNID + hol/prod MUST be paired with id/idSearch/rd/status/lcs (otherwise the backend rejects to avoid a 17M-row full scan); JPID has no HOL/PROD; USID has no STATUS; ed (expiration date) is silently ignored on all sources — filter dates via rd instead. With enableLitigation on, each page re-triggers the litigation query and billing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sourceYesData source (required). WIPO data is partitioned by source — cross-source queries not supported. Common: USID (US design), CNID (China design, 17M+ rows), HAGUE (Hague international), DEID, JPID.
dsNoDesignated country code (e.g. 'US', 'CN'). Optional — usually implied by `source`.
holNoHolder name fuzzy match. Examples: 'Apple' / 'Samsung' / 'Nike'. NOTE: CNID + hol MUST be paired with id/idSearch/rd/status/lcs; JPID has no HOL column (will be ignored).
prodNoProduct name fuzzy match. CNID searches Chinese, other sources search English. Examples: '椅子' (CNID) / 'wireless headphones' (USID) / 'iphone case' (USID). CNID + prod MUST be paired with id/idSearch/rd/status/lcs; JPID has no PROD column.
irnNoInternational Registration Number exact match. Examples: 'DM/000298' (HAGUE) / 'D1107730' (USID).
idNoFull ID exact match, e.g. 'CNID.2023.123456'. Routes CNID queries to a single partition (avoids full scan).
idSearchNoID variant fuzzy match.
rdNoRegistration date (YYYY or YYYY-MM-DD). One of the recommended narrowing fields for CNID — routes to a year partition.
statusNoLegal status: 'ACT' (active), 'EXP' (expired), etc. USID has no STATUS column (will be ignored).
lcsNoDesign classification (Locarno Classification code), e.g. '23-01' = fluid distribution equipment.
fromNoPagination offset, 0-based.
numNoPage size (default 10, max 100).
enableLitigationNoEnable Smart Risk Control Mode: after patents match, auto-query related US litigation (PACER backend) by patent number; cases are joined into each patent's `cases` field. Default false. When on, each matched patent gains litigationStatus / caseTotal / cases; +12 points charged only when a patent is found (free if none).
Behavior5/5

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

No annotations exist, so the description carries full burden. It discloses critical behavioral details: CNID+hol/prod pairing requirements, source-specific limitations (JPID no HOL/PROD, USID no STATUS, ed ignored), enableLitigation auto-chaining behavior, cost/performance (~2 points, 5s, +12 points only when patents found), and return structure. This is exceptionally transparent.

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 comprehensive but somewhat lengthy. However, it is well-organized with sections (description, use/don't use, returns, pair with, cost, perf contract) and front-loaded with a clear summary. Every sentence adds value, though conciseness could be slightly improved by condensing repeated 'CNID' warnings.

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 tool's complexity (13 parameters, no output schema, no annotations), the description is remarkably complete. It explains return data structure, pagination, litigation chaining, cost implications, and source-specific constraints. It also mentions pairing with other tools (e.g., DETAIL_URL for verification). This exceeds expectations for completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with parameter descriptions, but the description adds significant meaning beyond schema: pairing constraints (CNID + hol MUST be paired with id/idSearch/rd/status/lcs), source-specific behaviors (JPID no HOL/PROD, USID no STATUS), and usage notes for each parameter (e.g., 'Examples: 'Apple'' for hol). This enriches the agent's understanding.

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 clearly states the tool's purpose: querying WIPO design database across 12 sources with TRO risk control. It is specific ('Design Patent TRO risk control · WIPO global design / IP search') and distinguishes from sibling tools like search_amazon by explicitly stating it is an IP database, not a commerce database.

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?

The description provides explicit 'Use when' and 'Don't use' sections, listing example user queries (e.g., 'check trademark', 'design patent search') and explicitly excluding commerce-related searches. It also mentions pairing with source and other parameters, giving clear guidance on when to use this tool versus alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pangolinfo/pangolinfo-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server