Nexscope Ecommerce Data MCP

Nexscope Patent Image Search

nexscope_zhihuiya_patent_image_search

Perform visual similarity search for design patents using an image URL, with filtering by country, legal status, date ranges, Locarno classification, and assignee. Supports design patent types only (type D). Triggered when users mention patent image search, design patent search, search patent by image, visual patent lookup, patent similarity detection, patent image matching, or design patent infringement check. Even if the user does not explicitly mention "patent image," this skill should be triggered whenever the need involves searching for similar design patents through an image. For utility model patents, use ecommerce.zhihuiya-utility-patent-image-search instead.

Input Schema

Name	Required	Description
`loc`	No	LOC classifications (Locarno classification numbers). Join multiple classifications with AND, OR, or NOT
`url`	Yes	Image URL (maximum 1,000 characters)
`lang`	No	Preferred title language: original (original patent title), cn (Chinese-translated title), or en (English-translated title). Default: original
`field`	No	Result sort field: SCORE (relevance), APD (application date), PBD (publication date), or ISD (grant date). Default: SCORE
`limit`	No	Number of patents to return, from 1 to 100. Default: 10
`model`	Yes	Image-search model. Design patents: 1 (smart association, recommended) or 2 (search this image). Utility model patents: 3 (match shape) or 4 (match shape, pattern, and color; recommended)
`order`	No	Available when field is APD, PBD, or ISD: desc (descending) or asc (ascending). Default: desc
`offset`	No	Result offset, from 0 to 1,000. Default: 0
`country`	No	Patent authority codes for countries, organizations, or regions, separated by commas, for example CN,US,JP. Omit to search all patent authorities
`isHttps`	No	Whether to return images over HTTPS: 1 for HTTPS and 0 for HTTP. Default: 0
`stemming`	No	Whether to enable stemming: 1 for enabled and 0 for disabled. Default: 0
`assignees`	No	Applicant or patent owner (maximum 1,000 characters)
`mainField`	No	Primary patent fields, including title, abstract, claims, specification, publication number, application number, applicant, inventor, and IPC/UPC/LOC classifications (maximum 1,000 characters)
`preFilter`	No	Whether to enable country/LOC pre-filtering: 1 for enabled and 0 for disabled. Default: 1
`patentType`	Yes	Patent type D for a design patent; this skill uses D. Gateway default: D
`legalStatus`	No	Comma-separated patent legal-status codes. Values: 1 (published), 2 (substantive examination), 3 (granted), 8 (duplicate-grant avoidance), 11 (withdrawn), 12 (withdrawn-unspecified), 17 (deemed withdrawn), 18 (voluntarily withdrawn), 13 (rejected), 14 (fully revoked), 15 (expired), 16 (annual fee unpaid), 21 (rights restored), 22 (rights terminated), 23 (partially invalid), 24 (application terminated), 30 (abandoned), 19 (deemed abandoned), 20 (voluntarily abandoned), 25 (abandoned-unspecified), 222 (PCT did not enter designated state within designation period), 223 (PCT entered designated state within designation period), 224 (PCT entered designated state after designation period), and 225 (PCT did not enter designated state after designation period)
`returnImgId`	No	Whether to return img_id. Default: false
`applyEndTime`	No	Patent application end date in yyyyMMdd format
`publicEndTime`	No	Patent publication end date in yyyyMMdd format
`applyStartTime`	No	Patent application start date in yyyyMMdd format
`scoreExpansion`	No	Score expansion
`publicStartTime`	No	Patent publication start date in yyyyMMdd format
`simpleLegalStatus`	No	Comma-separated simplified patent legal-status codes. Values: 0 (inactive), 1 (active), 2 (pending), 220 (PCT designation period expired), 221 (within PCT designation period), and 999 (unconfirmed)
`includeMachineTranslation`	No	Include machine-translated data in the search

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 24, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations are minimal (readOnlyHint=false, openWorldHint=true), so the description could do more heavy lifting. It clarifies the patent-type constraint and hints at model semantics, but says nothing about cost, rate limits, result volume limits (limit caps at 100, offset at 1,000), or what a match record contains. Adequate but leaves real gaps for a search on an external patent corpus.

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 core purpose and the sibling exclusion are front-loaded in the first two sentences. The trigger-keyword list is long and somewhat repetitive with the purpose statement, but it serves a routing function and costs only a few lines.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 24-parameter tool with no output schema, the description covers purpose, scope, and routing well but never describes the shape of the result (patent numbers, images, similarity scores) or paging strategy. An agent knows when to call it but not what to expect back.

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%, so all 24 parameters are documented in structured form and the description adds little beyond restating the filter set. It does not clarify ambiguous parameters like scoreExpansion, stemming, or preFilter that the schema names but barely explains.

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 opening sentence names a specific verb and resource ('visual similarity search for design patents using an image URL') and enumerates the filter facets. It also scopes the tool to design patents only (type D), which is the key distinction from the utility-model sibling.

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 explicit trigger phrases and an expansive fallback rule ('triggered whenever the need involves searching for similar design patents through an image'). It names the alternative for utility model patents, ecommerce.zhihuiya-utility-patent-image-search, giving a clean routing decision.

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

All Nexscope Ecommerce Data MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?