Skip to main content
Glama
Pangolin-spg

Pangolinfo Amazon Data MCP

by Pangolin-spg
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

wipo_search

Query WIPO design databases across 12 sources to run IP clearance and US design-patent litigation/TRO risk checks before launch.

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
dsNoDesignated country code (e.g. 'US', 'CN'). Optional — usually implied by `source`.
idNoFull ID exact match, e.g. 'CNID.2023.123456'. Routes CNID queries to a single partition (avoids full scan).
rdNoRegistration date (YYYY or YYYY-MM-DD). One of the recommended narrowing fields for CNID — routes to a year partition.
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).
irnNoInternational Registration Number exact match. Examples: 'DM/000298' (HAGUE) / 'D1107730' (USID).
lcsNoDesign classification (Locarno Classification code), e.g. '23-01' = fluid distribution equipment.
numNoPage size (default 10, max 100).
fromNoPagination offset, 0-based.
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.
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.
statusNoLegal status: 'ACT' (active), 'EXP' (expired), etc. USID has no STATUS column (will be ignored).
idSearchNoID variant fuzzy match.
clientSourceNo调用来源标记。仅由 Pangolinfo Skill 传 skill；普通 MCP 调用省略即可。
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).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are supplied, so the description carries the full burden, and it does: exact cost (~2 points/call, ~5s), conditional +12 point litigation charge, billing re-trigger on pagination, backend rejection rules for CNID+hol/prod, and silent-ignore quirks (USID no STATUS, JPID no HOL/PROD, ed ignored). These are non-obvious operational behaviors an agent could not infer elsewhere.

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 purpose, then cleanly sectioned into Use when / Don't use / Returns / Pair with / Cost / Perf contract, so the density is navigable. It is on the heavy side and the 'Pair with' line partially restates schema param descriptions, but for a 14-parameter tool most sentences earn their 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 spells out the return shape (data.data.hits[], DETAIL_DATA fields, IMG_DATA, plus the litigationStatus/caseTotal/cases join) and the pagination/partition constraints. Nothing material for correct invocation is missing.

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?

Schema description coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: the aliasing map (hol/prod/irn/lcs), the required-source dependency, and the enableLitigation chaining behavior that ties one param to a whole litigation lookup.

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 verb and resource — 'Query the WIPO design database across 12 sources' — and names concrete sources (USPTO US designs, CNID, HAGUE). It also explicitly distinguishes itself from the surrounding commerce siblings by declaring this 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?

Provides an explicit 'Use when:' block with concrete trigger utterances ('check trademark', 'WIPO search', 'any IP risk for new product') and a 'Don't use:' block excluding keyword ranks, product reviews, and US text-trademark search. The when/when-not/alternative split is fully specified.

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

Deploy Server

Other Tools