Loading ToolBench
MCP Server that wraps the broker_core engine for AI-assisted product resale. Exposes 7 tools for photo analysis, price research, safety validation, listing generation, scheduling, price shielding, and auto-delisting across multiple platforms (Xianyu, Zhuanzhuan, eBay, Depop).
This server has significant definition quality gaps despite having explicit tool registration. While all 7 tools are registered with names, descriptions, and input schemas, the definitions lack depth and clarity for production LLM interaction. Tool names are action-oriented but descriptions are inconsistent in detail. Parameter schemas are present but lack granularity (no enums, minimal validation guidance). Output schemas are entirely absent from the documented interface. Critical issues include missing error recovery guidance, no security/permission hints, and vague parameter constraints. The server appears to target a specific workflow (resale agent) rather than general-purpose tool composition, which limits reusability.
Retrieve the complete immutable audit trail for a listing or view recent events. Returns all pricing decisions, fuse checks, publish actions, delists, repricing, and schedule registrations with timestamps.
Step 1: Analyze a product photo and extract structured product information. MUST be called FIRST in any resale workflow. Uses the Anthropic Vision API to identify brand, model, condition, material, flaws, etc. Returns a ProductInfo dict. Requires ANTHROPIC_API_KEY in environment.
Step 4: Generate a listing card for the product and auto-publish to selected platforms. Returns URLs of published listings on each platform.
Step 3 — MANDATORY GATE: Validate a suggested price against the hard-stop Price Shield (unbreachable floor price). Returns {blocked: true/false, reason: str}. If blocked==true, ALL downstream publish/repricing actions MUST be cancelled. This is the pricing safety boundary. Every check is logged to the immutable audit trail.
Step 2: Search authorized platforms for comparable listings and generate a transparency price report. Returns recommended price, median sold/active prices, market sentiment, and full rationale. MUST be called after cognitive_intake.
No output schemas documented for any tool. LLMs cannot predict return value structure, forcing them to blindly consume responses and guess at field availability. This violates pattern:tool and mxe:response-shaping. Examples: cognitive_intake returns 'ProductInfo dict' without field definitions; generate_xai_pricing mentions 'report' but no schema; execute_platform_action returns 'URLs' but structure is undefined.
Parameter constraints are missing enums and validation guidance. Example: condition_grade accepts 'A-E' as a string description, but not as a formal enum constraint. LLMs may pass invalid grades like 'excellent' or 'A+'. Similarly, 'platforms' in execute_platform_action is an array of strings with no enum of valid platform IDs (xianyu, zhuanzhuan, ebay, depop only?). Violates pattern:constrained-input.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
Step 3 (alternate): Trigger browser-based login for a resale platform. Opens browser, captures session cookies, persists them for future API calls.
Step 5: Register a repricing schedule for the listing. Auto-adjusts price at intervals (default 7 days) based on new market data. Registers with system cron/launchd for daily checks.
Error handling lacks recovery guidance. Tool descriptions mention side effects (e.g., fuse_gatekeeper 'blocks' actions, schedule_repricing registers with cron) but do not explain what the LLM should do if the operation fails. No examples of error responses provided. Violates pattern:recovery-guide.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Per current spec (2026-07-28), tools should declare their safety profile. execute_platform_action and schedule_repricing are clearly destructive (write state), but no annotation present. audit_trail_query is read-only. Missing annotations force LLMs to infer safety from descriptions alone.
No permission/scope declarations. Tools like execute_platform_action, schedule_repricing, and platform_auth_trigger modify state or trigger browser automation, but no explicit permission requirements stated. Per pattern:scope-declaration, each tool should declare required permissions (e.g., 'publish:listings', 'schedule:repricing'). Violates pattern:scope-declaration.
Parameter descriptions lack actionable constraints. Example: cognitive_intake's image_base64 parameter description says 'Base64-encoded image data' but does not specify size limits, supported formats, or what happens if the base64 is invalid. execute_platform_action's 'platforms' array lacks description of what constitutes a valid 'platform ID'. Review:param-validation-rules requires format, range, and allowed values in parameter descriptions.
Workflow sequencing is implicit in tool descriptions but not formally enforced. Tool descriptions say 'MUST be called FIRST' (cognitive_intake) and 'MUST be called after cognitive_intake' (generate_xai_pricing), but the MCP protocol has no way to express these dependencies. LLMs must infer ordering from text. This is fragile and invites out-of-order calls. Consider: (1) adding explicit prerequisites in parameter descriptions, (2) using tool annotations to mark sequence constraints, or (3) returning errors when preconditions are violated with clear guidance on the correct order.
No pagination documented for audit_trail_query, which returns 'recent events' up to a limit. The description mentions 'limit' parameter (default 50) but does not clarify: is there a total event count returned? How does pagination work if there are >50 events for a listing? No next_cursor or offset documented. Violates pattern:paginated-result.
No idempotency guarantees stated. Tools like execute_platform_action and schedule_repricing modify state, but descriptions do not clarify: if called twice with the same item_id, will it create duplicate listings or schedules, or idempotently update the existing one? Agents retry on failures, non-idempotent tools risk duplicates. Violates pattern:idempotent-operation.
Credentials and secrets handling is documented (ANTHROPIC_API_KEY in cognitive_intake) but scattered across implementation and docstrings rather than formally described in the tool interface. The rubric requires credentials NEVER appear as tool parameters (correctly absent here), but the MCP spec should also document server-side secret injection pattern. A client reading the tool schema cannot see that cognitive_intake requires ANTHROPIC_API_KEY, this is internal implementation detail. Add to server capabilities or initialize response.