linkfox-ehunt-temu-category-search

EHunt Temu category search (ehunt/temu/temuCategorySearch）

When the LinkFox "Third-Party Data Service" MCP is available, the corresponding gateway route ehunt/temu/temuCategorySearch is called (MCP display name:Temu Category Query; the exact tool name is subject to the tool metadata issued in the current environment). Data comes from local database search。

Prerequisites

The database must already contain the full set of categories written by ehunt/temu/syncTemuCategory(MCP display name:Temu Category Sync). If there is no data or the results are empty, complete the sync first before searching.

Key Points

• Required：keyword(substring match on category Chinese name, English name, category id).
• Pagination：page starts from 1;pageSize defaults to 50, maximum 200.
• The returned id / categoryId can serve as the category identifier for inputs such as categoryHome/categoryBackendfor Temu product queries, category for store queries, etc. (as long as it is consistent with the specific tool schema).

Script (Optional)

Command-line debugging:python scripts/ehunt_temu_category_search.py '<JSON>'(requires LINKFOXAGENT_API_KEY). See the end of references/api.md .

Reference

For the input/output parameter table, see references/api.md。

Handling Large Responses

To avoid overflowing the agent context, persist the response to disk and extract only the fields you need:

python scripts/response_io.py run --script scripts/ehunt_temu_category_search.py --out-dir <DIR> '<params>'
python scripts/response_io.py read <file> --fields "<paths>"   # or --path "<JMESPath>"

Pick --out-dir outside any git working tree (e.g. /tmp/... on Unix, %TEMP%/... on Windows). Persisted responses may contain PII, pricing, or auth-sensitive data — do not commit them. Files are not auto-deleted; clean up when the task is done.

run writes the full response to a file and emits only a schema preview + file path. read projects specific fields, with --limit/--offset for slicing and --format json|jsonl|csv|table for output.

When to prefer this pattern — apply your judgment based on the response characteristics, e.g.:

• High field count per record, or fields you don't need
• Batch/paginated results (multiple items per call)
• Long-text fields (descriptions, reviews, HTML, time series)
• Output reused across later steps rather than consumed immediately

For small, single-use responses, calling the main script directly is fine.

⚠️ The preview is a truncated schema + sample, not the full data. Any field-level decision must read from the persisted file via read.