Server has 11 tools with complete input schemas and descriptions present for all tools. Naming follows verb_noun convention (stubhub_search, stubhub_get, stubhub_add, stubhub_checkout). Parameter descriptions are present but often generic ('Event ID or full StubHub event URL' repeated 5+ times). Critical gap: no output schemas documented anywhere, LLMs cannot infer what fields to expect from responses. Error handling is absent from tool definitions. The stubhub_checkout tool has a critical confirmation pattern but lacks structured error guidance for the irreversible operation. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels assigned.

• Add output schemas to all tools. Document response structure: e.g., stubhub_search_events returns {events: [{id, name, date, venue, minPrice}], total, nextCursor}. This enables agents to chain calls and extract required fields.
• Implement tool annotations in inputSchema. Add 'readOnlyHint': true to GET tools, 'destructiveHint': true to DELETE/LOGOUT, 'idempotentHint': true to idempotent operations. Agents use these to reason about safety.
• Expand tool descriptions to 100-200 chars with WHEN/WHY context. E.g., 'Search for events by artist, team, or show name. Use this first to find event IDs before calling get_event or get_listings. Supports filters: category (concerts/sports/theater), location (city name).'
• Document error responses for stubhub_checkout. Specify: 'If confirm=true and payment fails, returns {error: "payment_declined", code: "PAYMENT_ERROR", recovery: "Check payment method and retry, or call stubhub_get_orders to verify if charge succeeded."}' This guides agent recovery.
• Add pagination metadata to list responses. Document: 'Returns up to maxResults items. If total > returned items, use offset parameter in next call. Always include total_count and has_more in response.' Prevents context window exhaustion.