Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
Blinkit MCP exhibits significant structural and documentation gaps that prevent it from meeting production quality standards. While 24 tools are registered with schemas via Zod validation, critical inspections reveal: (1) Tool descriptions are sparse or generic across most tools, cannot see full description text in source, suggesting minimal or boilerplate content. (2) Parameter descriptions are not visible in the provided source code excerpts; Zod schema definitions are imported but not shown, making it impossible to verify parameter documentation. (3) Output schemas are not documented, responses are wrapped in a generic ContentBlock structure with no field definitions for downstream tool chaining. (4) Error handling is minimal: a catch-all error handler logs and optionally captures a screenshot, but does not classify errors as retryable, user-fixable, or fatal, nor does it guide LLM recovery. (5) High-risk tools (pay_now, quick_upi_checkout, clear_cart) have IRREVERSIBLE or DESTRUCTIVE classifications but no confirmation/dry-run pattern visible. (6) Tool composition has potential issues: multiple checkout paths (checkout, quick_upi_checkout) without clear distinction; parameter naming not verified (e.g., no visibility into whether location tools accept user-friendly names vs IDs only). (7) No visible pagination support despite retail scenarios where search_products and get_order_history likely return large result sets. Average per-tool definition quality is estimated at 38/100 based on missing/unverifiable schema details, minimal descriptions, and lack of downstream chaining IDs.
Tool descriptions not visible in source code. Server.ts shows tool registration but description text is not included in the provided excerpts. Cannot verify against 10 - 1024 char baseline or LLM-optimization criteria.
check_login_statusloginenter_otplogout
Recommendations
Export and document full input schemas for each tool. Include parameter names, types, descriptions, enums for constrained values, and min/max bounds. Post schemas in individual tool files (e.g., src/tools/auth/login.ts) as TypeScript interfaces or JSDoc comments that are visible in source code review.
Expand tool descriptions to 50 - 200 characters each. Answer: What does it do? When should the LLM call it? What does it return? Example: 'Search Blinkit products by name or category. Returns matching items with prices, stock status, and product IDs. Use before add_to_cart.'
Add parameter descriptions to every input field. Disambiguate 'type' params, specify valid enum values, document format constraints (e.g., 'latitude: float, -90 to 90'), explain dependencies between parameters. Example: 'quantity: integer, 1 - 100. Must match item availability returned by search_products or get_product_details.'
Document output schemas explicitly. For each tool, describe what fields it returns, their types, and range. Example for search_products: 'Returns {items: [{id, name, price_inr, stock_status, category_id}], total_count, has_next_page}'.
Implement error classification in the error handler. Catch different error types (NetworkError, ValidationError, PermissionError, TimeoutError) and return structured error responses: {isError: true, errorType: 'retryable'|'userFixable'|'fatal', message, suggestion}. Example: 'User not found. Try login() with phone number or email.'
Add confirmation/dry-run support for irreversible operations. For pay_now and quick_upi_checkout, require a confirm_payment=true parameter or add a separate dry_run_checkout tool that previews the charge without executing.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Irreversible/destructive operations (pay_now, quick_upi_checkout, clear_cart) lack explicit confirmation or dry-run support. Agents making mistakes could trigger unintended payments or data loss.
Generic error handling: catch-all block returns error message and optional screenshot. No error classification (retryable vs. user-fixable vs. fatal), no recovery guidance. LLM cannot determine next action.
Output schemas not documented. ContentBlock union is defined but no field schema for actual response payloads. Downstream tool chaining impossible without LLM guessing response structure.
No visible pagination support. search_products, browse_category, get_order_history likely return large result sets but no page/limit/offset parameters detectable in source.
Parameter naming not verifiable from source excerpts. Location tools (set_location, select_address) do not show whether they accept human-friendly names (e.g., 'home', 'office') vs. opaque system IDs. Requires natural-identifier acceptance per pattern.
No visible audit logging or permission gates. Tools that modify user data (login, pay_now, clear_cart) do not show access control or audit trail implementation.
loginpay_nowclear_cartcheckoutquick_upi_checkout
Implement pagination for list and search tools. Add limit (default 20, max 100) and cursor/offset parameters to search_products, browse_category, get_order_history. Return total_count and next_cursor in responses.
Consolidate checkout paths. Merge quick_upi_checkout into checkout with a payment_method parameter (enum: 'upi', 'card', 'wallet'), or rename quick_upi_checkout to pay_with_upi for clarity. Verify both paths do not coexist without clear distinction in descriptions.
Accept human-friendly location identifiers. Modify set_location and select_address to accept address_name (enum: 'home', 'office', 'other') in addition to lat/lon, or add a lookup tool that maps names to coordinates internally.
Add audit logging. Log every tool call with: timestamp, tool_name, user_id/session_id, input parameters (excluding secrets), output summary, success/error. Route logs to a file or structured logging backend, not just stderr.
Add rate limiting and spending guards. Implement per-user call limits (e.g., 10 checkout calls/minute) and enforce the spending guards already present in SpendingGuard service. Return clear rejection messages: 'Daily order limit reached. Current spend: $85 of $100 limit.'
Verify parameter types in schemas match expected inputs. For example, if select_payment_method expects a payment_method_id, ensure get_payment_methods returns payment_method_id (not id, not method_id). Alignment prevents LLM field mapping errors.
Include downstream chaining IDs in responses. If checkout returns an order_id, ensure it can be passed directly to track_order. If add_to_cart succeeds, return the cart_id or item_id that can be passed to update_cart_item.
Strip unnecessary metadata from responses. Filter out internal API fields (timestamps, version IDs, audit fields) that clutter the token count. Return only user-relevant data: product name, price, availability status, not raw API blobs.