Easyparser — Amazon Product & Seller Data

get_bulk_job_items

Read-only

Inspect the individual items inside a bulk job: each item's input value (ASIN, keyword, seller ID...), its status (success/failed/invalid/pending/processing), error message if it failed, credit cost, and completion time.

Use this tool to debug a job after list_bulk_jobs shows failed_items or invalid_items > 0 — filter with status='failed' or status='invalid' to see exactly which inputs failed and why. Use search_key to locate one specific ASIN inside a large job. The item's item_id can be used with the Data Service (GET /v1/queries/{id}) to fetch its parsed result.

This tool is free of per-call credits (monitoring endpoints do not consume credits).

Input Schema

Name	Required	Description	Default
`page`	No	Page number. Default 1.
`limit`	No	Items per page (max 1000). Default 100.
`status`	No	Filter items by outcome. Use 'failed' or 'invalid' to debug a partial_success job; omit to see everything.
`date_to`	No	ISO date upper bound.
`group_id`	Yes	The job's group_id — get it from list_bulk_jobs (each job row has one). Identifies which job's items to inspect.
`date_from`	No	ISO date lower bound, e.g. 2026-08-01.
`search_key`	No	Search within item values (e.g. a specific ASIN) to find one item in a large job.
`sort_direction`	No	Sort by creation time. 'desc' (newest first) is default.	desc

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 11, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "description": "JSON response from the Easyparser Data Service or Account API. Non-object payloads are wrapped as { result }.",
+  "properties": {},
+  "type": "object"
+}

First observedSep 6, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, destructiveHint=false), but the description adds real behavioral context: monitoring endpoints consume no per-call credits, and each item's item_id can be chained to GET /v1/queries/{id} for the parsed result. It does not discuss pagination limits or job-completeness caveats, but the additions are meaningful.

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?

Three short paragraphs with the core purpose front-loaded, then usage, then cost/next-step. Efficient overall, though the status-filter guidance and search_key explanation duplicate what the schema descriptions already say, costing some redundancy.

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?

Complete for an 8-parameter read-only inspection tool: it covers why to call it, how to narrow results, what each item contains, that it is free, and how to escalate to a sibling endpoint for the parsed result. An output schema exists, so return-shape explanation is correctly omitted.

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 the schema already documents every parameter, including the status filter guidance and search_key purpose. The description's parameter-related statements largely restate the schema rather than adding syntax, defaults, or format details. Baseline 3 applies.

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 ('Inspect the individual items inside a bulk job') and enumerates what an item contains (input value, status, error message, credit cost, completion time). This is clearly distinguishable from siblings like list_bulk_jobs (job-level) and get_bulk_item_result (parsed result).

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?

Gives an explicit trigger ('after list_bulk_jobs shows failed_items or invalid_items > 0'), the exact filter recipe ('status="failed" or status="invalid"'), and a secondary use case (search_key to locate one ASIN in a large job). It also routes the agent onward to the Data Service with the item_id.

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

All Easyparser — Amazon Product & Seller Data 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.